La conversación cerrada que silenciaba al cliente

Si atiendes clientes por chat y cierras la conversación cuando la venta termina, esta nota te interesa. Cuenta un fallo nuestro que dejaba mudos a los clientes que volvían, y cómo se corrige.

El estado de una conversación lo mantiene un disparador de la base de datos, una regla que se ejecuta sola cada vez que entra un mensaje. Recalcula si el hilo está «esperando» respuesta del negocio, «contestado» o «cerrado». El disparador original tenía esta rama: WHEN status = 'cerrada' THEN 'cerrada'. Una conversación cerrada seguía cerrada, pasara lo que pasara.

Por encima tiene lógica. Cerrada es un estado final, y los estados finales no cambian. Es la lógica que se rompe en cuanto el cliente vuelve a escribir.

En el CRM hay un solo hilo por persona y canal. Lo obliga la base de datos. Así que cuando un cliente con la conversación cerrada volvía a escribir, su mensaje no caía en otro sitio. Caía en ese hilo cerrado.

Se guardaba. La fecha del último mensaje subía. Y como los hilos cerrados no aparecen en la bandeja de trabajo, nadie lo veía. Nunca.

No era un mensaje perdido. Era una persona que dejaba de existir para el negocio en el momento en que alguien le cerraba la venta anterior. Y seguía escribiendo.

Cerrar una venta ganada silenciaba al cliente que volvía a comprar. Es el fallo más caro posible para un producto que promete «no pierda otro cliente por contestar tarde».

La regla nueva del disparador distingue de quién es el mensaje. Un mensaje del cliente reabre siempre. La conversación pasa a «esperando», aparece en la bandeja y alguien la ve.

Un mensaje del negocio no reabre. Si lo hiciera, una campaña a quinientas personas abriría quinientos hilos que nadie pidió. La bandeja de trabajo quedaría enterrada bajo conversaciones que no esperan nada.

La misma distinción rige el reparto automático, el que le asigna cada conversación a alguien del equipo. Se engancha cuando entra un mensaje de cliente y el hilo no tiene dueño, no cuando el hilo se crea. Así alcanza al cliente que escribió hace tres meses, cuyo hilo se cerró, y vuelve hoy. Que es exactamente el que el producto promete no perder.

Corregir el disparador arregla el futuro. La migración miró también el pasado, y a eso se le llama backfill: reparar hacia atrás lo que ya estaba guardado. Buscó todos los hilos cerrados cuyo último mensaje era del cliente, y los reabrió.

Cada uno de ellos era una persona que había escrito después del cierre. Llevaba días o semanas sin respuesta, y nadie en el negocio podía enterarse.

No publicamos la cifra, porque es de nuestros clientes. Publicamos que existía, porque ese es el dato que importa: el fallo no era teórico.

Al diseñar los estados por los que pasa algo, uno piensa en las salidas: desde aquí se puede ir allá. El error estaba en las entradas.

«cerrada» se había pensado como destino, y nadie preguntó qué debía pasar cuando desde fuera llegara un evento que no encaja con «terminal». Un cliente que escribe es ese evento. Ningún estado de una conversación con un ser humano es terminal mientras el humano pueda escribir.

Queda la trampa de la restricción. El hilo único por persona era correcto: impide duplicados y mantiene el historial junto. Pero convirtió un estado mal pensado en un agujero sin fondo, porque el mensaje no tenía otro sitio donde caer.

• Preguntar: «Si cierro una conversación y el cliente vuelve a escribir mañana, ¿dónde aparece?». La respuesta tiene que ser «en la bandeja, esperando».
• Preguntar: «Si mando una campaña a 500 personas, ¿cuántas conversaciones abiertas tengo después?». La respuesta buena es «las mismas que antes, más las que contesten».
• Pedir el número: «¿Cuántos hilos cerrados tienen como último mensaje uno del cliente?». Si no es cero, hay gente esperando.
• Recorrer, si construyes el sistema, cada estado preguntando no qué sale de él, sino qué puede llegarle desde fuera.