El caso: el mensaje que llegó después del acuerdo
Un individuo hipotético firma un acuerdo de pago un lunes por la tarde. El martes por la mañana recibe un SMS recordándole su deuda con un tono de urgencia, seguido el miércoles por una llamada automatizada preguntando si puede pagar hoy. El individuo, que ya había cumplido su parte, llama molesto preguntando si el acuerdo "no cuenta" o si hay algún error.
Este tipo de situación no es un error de contenido, es un error de supresión: el sistema de comunicaciones no se enteró a tiempo de que el caso ya no debía recibir más contactos de gestión activa.
Por qué la supresión es una función crítica, no un detalle técnico
En cualquier motor de comunicaciones masivas, enviar el mensaje correcto es solo la mitad del trabajo. La otra mitad, con frecuencia menos visible, es saber cuándo dejar de enviar. Un mensaje bien redactado que llega después de un acuerdo, un pago, o una solicitud explícita de no ser contactado no solo es inútil: daña la credibilidad de todo el proceso y puede convertir a un individuo cooperativo en uno defensivo.
Casos que siempre deben suprimir contacto
- Pago total registrado, incluso si la confirmación bancaria tarda en llegar.
- Acuerdo de pago estructurado y confirmado, con monto, fecha y medio de pago todos definidos.
- Solicitud explícita de no contacto por un canal específico o por todos.
- Caso identificado como disputa o reclamo en curso, hasta su resolución.
- Individuo fallecido o con incapacidad legal confirmada, según lo reportado por sus representantes.
El desafío técnico detrás de un caso simple
Suprimir a un individuo suena sencillo, pero en la práctica requiere que la información viaje rápido entre sistemas que no siempre se actualizan al mismo ritmo. Si el acuerdo se registra en un sistema y la cola de envíos ya estaba armada desde antes en otro, el mensaje de gestión activa puede salir igual, sin que nadie lo haya "querido" enviar.
Una arquitectura de supresión confiable necesita revisar el estado del caso lo más cerca posible del momento de disparo, no solo al armar la cola del día. Un caso puede pasar de "gestión activa" a "acuerdo cerrado" en cualquier momento, incluso minutos antes de que un mensaje programado esté por salir.
Supresión no es lo mismo que silencio total
Suprimir la gestión de cobro no significa desaparecer: significa cambiar el motivo del contacto.
Un error opuesto al del ejemplo inicial es interpretar la supresión como "no volver a contactar nunca". Un individuo con un acuerdo activo sigue necesitando comunicación, pero de otro tipo: recordatorios de cuota, confirmaciones de pago recibido, o aviso si una cuota no se acreditó. La supresión correcta apaga los mensajes de presión y de oferta, no todo el canal de comunicación con el individuo.
Cómo verificar que la supresión está funcionando
- Auditar periódicamente una muestra de casos con acuerdo activo para confirmar que no recibieron mensajes de gestión fuera de lo esperado.
- Revisar el tiempo que transcurre entre el registro de un pago o acuerdo y la actualización del estado en el sistema de envíos.
- Registrar y monitorear reclamos de individuos que recibieron contacto después de haber cumplido, como indicador temprano de fallas.
- Probar el flujo de supresión con casos de prueba antes de cada actualización relevante del motor de comunicaciones.
El costo de no suprimir a tiempo
Más allá de la incomodidad puntual, cada contacto indebido después de un acuerdo erosiona la confianza que costó semanas construir. Un individuo que se siente ignorado en su cumplimiento tiene menos incentivo para cumplir el próximo compromiso, y puede compartir su mala experiencia con otros deudores en situación similar. En un modelo donde la relación con el individuo es progresiva y depende de la credibilidad de cada mensaje, la supresión oportuna no es un extra de cortesía: es parte del producto.
Diseñar bien la supresión, con la misma atención que se le da al contenido de los mensajes, es lo que permite escalar la comunicación masiva sin perder la coherencia de trato individual que cada acuerdo merece.
Más sobre Casos y prácticas
Segmentar por nivel de balance: un caso con tres carteras
Un caso hipotético con tres balances distintos muestra por qué aplicar el mismo funnel a toda la cartera desperdicia margen en ambos extremos.
De la promesa de pago al acuerdo cumplido
Un caso hipotético distingue la promesa vaga del acuerdo estructurado y propone reglas simples para que los planes de pago se cumplan en la práctica.
Cómo diseñar una oferta progresiva sin regalar margen
Un caso hipotético de tres tramos de descuento explica por qué la progresión solo funciona cuando cada oferta se gana con tiempo, canal o compromiso de pago.