Saltar al contenido
nvíame
Capítulo 3 de 511 min18 sep 2026

Menús, quick replies y handoff humano

Reduce la ambigüedad con opciones guiadas y deriva a una persona en el momento justo.

Las quick replies son botones efímeros que sugieren la siguiente respuesta. Reducen errores de tipeo, aceleran la conversación y hacen visible lo que el bot sabe hacer.

  • Etiquetas cortas y con verbo: «Ver pedido», «Cambiar dirección».
  • Siempre una salida: «Hablar con una persona».
  • Acepta también el texto equivalente: el usuario puede escribir en lugar de pulsar.

Derivación a humanos

El handoff transfiere la conversación a un agente humano. Debe ocurrir cuando el usuario lo pide, cuando el bot falla dos veces seguidas en entender, o cuando el tema es sensible (reclamos, fraude). Al derivar, envía al agente el resumen y el historial: que el usuario no tenga que repetir nada.

if (intent === "humano" || session.misses >= 2) {
  await handoff.create({
    user: session.userId,
    summary: summarize(session.history),
    priority: session.topic === "fraude" ? "alta" : "normal",
  });
  return reply("Te comunico con una persona del equipo. Suele tardar 2 minutos.");
}

Los menús reducen la ambigüedad: en lugar de adivinar qué quiso decir el usuario, le ofreces opciones. Las quick replies son la versión rica de ese menú, pero el bot debe aceptar también el número de opción o la palabra escrita, porque en SMS no hay botones.

El handoff es el momento en que el bot reconoce su límite y transfiere a una persona. Hacerlo bien significa conservar el contexto: el agente debe ver la conversación completa y los datos ya recolectados, para que el usuario no repita nada.

Pruébalo

// Numbered menu that also accepts words, with human handoff
const MENU = "Elige una opción:\n1) Estado de mi pedido\n2) Cambiar dirección\n3) Hablar con una persona";
let intentosFallidos = 0;

mx.bot.onMessage(({ text }) => {
  const t = text.trim().toLowerCase();
  if (t === "1" || t.includes("estado")) { intentosFallidos = 0; return mx.bot.reply("Tu pedido #4821 está en reparto. Llega hoy."); }
  if (t === "2" || t.includes("direcc")) { intentosFallidos = 0; return mx.bot.reply("Envíame la nueva dirección en un solo mensaje."); }
  if (t === "3" || t.includes("persona") || t.includes("agente")) {
    return mx.bot.reply("Te conecto con el equipo. Les dejé tu pedido #4821 para que no repitas nada. ⏳");
  }
  intentosFallidos++;
  if (intentosFallidos >= 2) return mx.bot.reply("Parece que no te estoy ayudando. Te paso con una persona. ⏳");
  return mx.bot.reply("No te entendí. " + MENU);
});

mx.bot.reply("Hola 👋 " + MENU);
Se completa automáticamente al leer el 80%.

Comentarios (3)

Valentina Muñoz18 sep 2026

¿Cuántas opciones debe tener un menú?

Equipo nvíameAutor18 sep 2026

Entre tres y cinco. Más que eso obliga a leer demasiado en una pantalla pequeña. Si necesitas más, agrupa en niveles o permite texto libre con interpretación.

Joaquín Vega18 sep 2026

Lo apliqué en el proyecto del trabajo. La sección «Menús, quick replies y handoff humano» me ahorró una discusión larga con el equipo: ahora tenemos un criterio compartido.

Matías Herrera18 sep 2026

¿Hay alguna diferencia importante si lo implemento en un servicio con varias instancias detrás de un balanceador?

Equipo nvíameAutor18 sep 2026

Sí: todo estado que hoy vive en memoria (contadores, sesiones, claves vistas) debe moverse a un almacén compartido con TTL, como Redis. Si no, cada instancia ve solo una parte de la historia.

Los comentarios se guardan solo en este navegador.