Reasignar no es borrar: partir un permiso demasiado ancho

Si en tu negocio varias personas atienden el mismo WhatsApp, esta nota va de un permiso mal cortado. Al final sabrás por qué repartir conversaciones y borrar historiales nunca deberían ir en el mismo paquete.

En una tienda con tres vendedores atendiendo el mismo WhatsApp, el gesto más repetido del día es este: «esta la llevo yo», «esto es de posventa, tómala tú». Tomar una conversación y pasársela a un compañero. Veinte veces al día, sin pensarlo.

En nuestro CRM ese gesto estaba detrás de un permiso llamado chat.assign, que el rol de Asesor no llevaba. Así que pasaba una de dos cosas. O el dueño repartía a mano todo lo que entraba. O los tres vendedores miraban el mismo hilo nuevo y dos contestaban a la vez, que es el problema exacto que el producto dice resolver.

La solución obvia era darle chat.assign al Asesor. No se podía, porque ese mismo permiso autorizaba otras dos cosas. Una era configurar los equipos y los turnos de reparto, tarea de quien coordina. La otra era vaciar o eliminar el historial completo de un cliente.

Dar el gesto cotidiano significaba, de paso, dar el poder de borrar datos personales para siempre. El comentario original del código lo admitía sin rodeos: «es el permiso más cercano que existe hoy; si acaba haciendo falta uno propio, se añade». Hizo falta.

La diferencia de fondo no es de jerarquía. Es de consecuencias. Reasignar una conversación se deshace: se mueve de vuelta y no pasó nada. Borrar el historial de un cliente no se deshace. Y además es tratamiento de datos personales bajo la Ley 1581, del tipo que hay que poder justificar.

Dos acciones con riesgos tan distintos no pueden compartir permiso. Si lo comparten, o se bloquea la inofensiva por miedo a la grave, o se regala la grave por necesitar la inofensiva.

La frase que resume la decisión es del propio código: «lo que se mueve es el gesto, no el rol». Al Asesor no se le dio un permiso de coordinador. Se movió el gesto de tomar y pasar al permiso que el Asesor ya tenía, el de atender, porque ahí es donde vive.

Partir un permiso con el sistema ya en marcha tiene una trampa. El día del cambio, alguien que ayer podía borrar deja de poder. O alguien que no podía, empieza a poder.

La migración se escribió para que ningún rol ganara ni perdiera nada. A todo rol que tuviera chat.assign se le dio chat.purge, porque eso es lo que tenía en la práctica. Sin ese paso, ese día ningún rol habría podido borrar nada. Y solo después, con calma, el dueño decide a quién le quita el permiso nuevo.

Ya que se creó el permiso, se definió con precisión qué borra cada cosa. Vaciar una conversación borra los mensajes y conserva el hilo. También limpia la fecha del último mensaje, para que el hilo no quede mal ordenado con una fecha fantasma.

Eliminar la conversación borra el hilo con sus mensajes, pero conserva el contacto. La persona sigue existiendo para el negocio, con su historial en los otros canales. Borrar el contacto es otra acción, aparte, porque se lleva todo.

Y cerrar una conversación pide confirmación, mientras que reabrirla no. Un clic involuntario no debe archivar nada. Reabrir no destruye nada. La fricción va donde va el riesgo.

• Preguntar, para cada permiso, qué acciones autoriza y cuál es la más grave. Si la más grave y la más cotidiana están juntas, partirlo.
• Diseñar los permisos por gesto («tomar una conversación») y no por jerarquía («coordinador»).
• Separar lo reversible de lo irreversible, siempre.
• Al partir un permiso con el sistema en marcha, conservar ese día el acceso efectivo de todos los roles. Después, recortar.
• Definir con palabras qué borra cada botón: los mensajes, el hilo o la persona.