Un flujo de venta normal vende un producto por pedido. Si tu cliente quiere dos anticuchos y una chicha, hace falta el carrito: la forma de que los productos sumen en vez de reemplazarse.
Esto se configura en el JSON del flujo
El problema que resuelve
Cuando un cliente aprieta un botón de producto, el flujo guarda el precio de ese producto en un sitio de nombre fijo. El segundo producto escribe encima del primero.
La consecuencia es fácil de pasar por alto porque el bot no da ningún error: un flujo con un botón «ver otro producto» que devuelve al catálogo no está acumulando, está empezando un pedido nuevo. El cliente cree que va sumando y al confirmar le llega el precio de lo último que tocó.
Cómo se enciende
El carrito es opcional y por paso. Un flujo que no lleva estas claves se comporta byte a byte como antes, así que se puede añadir a un flujo que ya está vendiendo sin migrar nada.
La clave es cartAdd, y va en el paso donde el producto ya está completamente elegido — normalmente el paso de la cantidad, porque ahí ya se conocen el producto, su precio y cuántos quiere:
// El paso de la cantidad, donde "plato" es la variable del catálogo:
"cartAdd": "plato"
// Solo algunos botones del paso:
"cartAdd": { "var": "plato", "buttons": ["1", "2"] }
// Cantidad fija, sin preguntar:
"cartAdd": { "var": "plato", "qty": 6 }Cada línea del pedido se arma con tres datos que ya existían en el flujo:
- El nombre sale de los nombres legibles del paso del catálogo. Sin ellos, la línea dice el identificador del botón.
- El precio sale de la tabla de precios de ese paso del catálogo. Un
cartAddsobre una variable que ninguna tabla de precios llena mete todo a S/0 — el validador de flujos lo rechaza antes de que llegue a un cliente. - La cantidad sale del botón que el cliente acaba de pulsar. Lo de abajo.
De dónde sale la cantidad
Los botones de cantidad tienen que llamarse 1, 2 y 3
"2"), son 2 unidades; cualquier otro identificador entra como 1. Un botón de cantidad llamado dos_unidades cobrará una sola.Esto es deliberado y evita un error de dinero que no da ninguna señal. Si la cantidad se leyera de lo que el cliente eligió antes, un paso de delivery con carrito cobraría «3 x Delivery» por haber pedido tres anticuchos. Al leerla del clic, el delivery entra como una unidad, que es lo correcto.
El corolario útil: un producto sin paso de cantidad funciona poniendo cartAdd en el propio paso del catálogo. Entra una unidad.
Mostrar el pedido
En cualquier mensaje posterior, la variable {cart_text} escribe el pedido ya formateado: una viñeta por línea con su subtotal, y el total en negrita. Va lista para pegar; no hace falta envolverla en otro formato.
Tu pedido:
{cart_text}
¿Confirmamos?Cuidado con la longitud del mensaje
Corregir un pedido
Corregir es vaciar y rehacer. Se vacía con cartClear, acotado al botón que debe hacerlo, porque en un paso «Tu pedido» hay otros botones que no deben borrar nada:
// En el paso "Tu pedido":
"cartClear": ["carrito_vaciar"]No existe «quitar solo la chicha», y no es un descuido: haría falta un menú construido en el momento con lo que el cliente ya lleva, y los botones de un flujo se escriben al diseñarlo. Con tres botones por pantalla, ese hueco vale más para otra cosa.
Botones pulsados en un mensaje viejo
Un cliente puede subir en el chat y volver a tocar un botón de hace diez mensajes. En ese caso el flujo navega, pero no vuelve a sumar: nadie paga dos veces por rebuscar en la conversación. La excepción es vaciar, que sí se hace siempre — es lo que el cliente pidió y repetirlo no cambia nada.
Cerrar el pedido después de cobrar
El carrito sobrevive al cobro
La solución no es tapar ese estado, es no poder llegar a él: después de cobrar, al paso final. Volver a pedir es escribir de nuevo al bot, lo que abre una sesión limpia con el carrito vacío — gratis y sin estados raros.
Como cinturón para el cliente que no toca nada y deja la conversación abierta, pon además "cartClear": true en ese paso de confirmación.
Límites y avisos
- Diez líneas por pedido. Al llegar al tope, el flujo puede derivar a una persona: existe una señal para usar en un paso de condición y mandar los pedidos grandes a un operador.
- Solo en pasos de botones. En un menú de lista el motor guarda el título de la fila y no su identificador, así que el carrito no encuentra ni el precio ni la cantidad.
- El agente de IA ve el pedido tal como lo lee el cliente. Si la conversación pasa de un flujo a un agente, este sabe qué lleva pedido.
- Se ve igual en la simulación. El playground de un flujo usa exactamente la misma lógica que el bot real, así que el pedido que ves al probar es el que recibirá el cliente.