La mayoría de las implementaciones de SMS que me toca ver son de una sola dirección: la empresa manda, el usuario recibe, y si el usuario responde, esa respuesta no llega a ningún lado. El SMS bidireccional es, probablemente, la funcionalidad con mejor relación entre esfuerzo de implementación y valor de negocio que existe hoy en mensajería empresarial.
Qué se resuelve con una respuesta de una sola palabra
- Confirmar o reagendar una cita, sin que la persona tenga que llamar al centro de contacto.
- Validar que una entrega llegó, respondiendo un número.
- Pedir que un asesor devuelva la llamada, sin esperar en línea.
- Confirmar una operación sensible con una segunda acción explícita del cliente.
- Darse de baja de comunicaciones comerciales sin fricción, que además es lo que corresponde.
El cálculo económico es directo: cada una de esas interacciones, resuelta por mensaje, es una llamada que no entra al centro de contacto. Y el costo por mensaje es previsible, algo que no siempre se puede decir de un minuto de agente.
Cuatro definiciones que conviene tomar antes de encenderlo
1. Contexto
Cuando llega un “SÍ”, el sistema tiene que saber a qué mensaje responde. Sin correlación entre el envío original y la respuesta, lo que queda es una bandeja de entrada sin significado.
Técnicamente esto se resuelve con un identificador de conversación asociado al envío y una tabla que relacione número, remitente y última interacción. Suena trivial hasta que dos áreas distintas le escriben al mismo cliente desde el mismo remitente el mismo día. Ahí la correlación deja de ser un detalle.
2. Ventana de validez
Cuánto tiempo sigue siendo válida una respuesta. Un “SÍ” tres semanas después no es una confirmación: es ruido, y en algunos casos es un problema. La ventana debería definirla el negocio —no el equipo técnico— y depende del proceso: confirmar una cita de mañana no tolera lo mismo que confirmar una entrega.
3. Salida a un humano
Siempre va a haber alguien que conteste algo que no está previsto. Ese mensaje tiene que llegar a una persona, no a un log que nadie abre. Es el punto donde más implementaciones fallan: se diseña el camino feliz y se deja el resto sin destino.
4. Tolerancia al lenguaje real
La gente escribe “si”, “Sí”, “SI.”, “sí por favor”, “sip”, “dale”. Si el parser solo acepta una forma exacta, el ajuste va de nuestro lado, no del usuario.
Números largos, cortos y alfanuméricos: qué permite responder
| Tipo de remitente | ¿Admite respuesta? | Cuándo conviene |
|---|---|---|
| Alfanumérico (nombre de marca) | No, en general | Notificación pura, cuando no se espera vuelta |
| Número corto | Sí | Alto volumen y necesidad de interacción sostenida |
| Número largo dedicado | Sí | Casos donde importa la continuidad de la conversación |
Esta es la decisión que más condiciona el diseño y la que más seguido se toma por inercia. Un alfanumérico se ve mejor en la bandeja del usuario, pero cierra la puerta de vuelta. Si el proceso necesita respuesta, el remitente debe elegirse por eso, no por estética.
Lo que más me gusta del canal de vuelta
Convierte una notificación en una conversación, con costo previsible y sin pedirle al cliente que instale nada.
Ese último punto es el que suele decidir. No hay app que descargar, ni registro, ni actualización de sistema operativo. Funciona en el teléfono que el cliente ya tiene, sea cual sea. En un país con la diversidad de dispositivos que tiene México, eso no es un detalle menor: es cobertura real.
Y es, además, el puente natural hacia canales más ricos. Quien ya resolvió contexto, ventana, escalamiento y tolerancia al lenguaje tiene el trabajo difícil hecho cuando decida sumar canales enriquecidos. Quien no, va a tener que resolverlo igual, pero con más superficie y menos margen.
¿Lo tienen habilitado, o hoy sus mensajes salen y nadie escucha la vuelta?