Developers
El patrón de catálogo con carrito adentro del chat
Vender por chat suele terminar igual: el bot manda un link, la persona abre el navegador, se pierde, y vuelve a preguntar en el chat.
El patrón que funciona es no sacarla nunca. Mostrar el catálogo adentro, dejar que arme la canasta ahí, y que el pedido salga como un mensaje.
Las piezas
La burbuja. Una tarjeta chica en el chat: miniatura, título, una línea y un botón. Ocupa poco y no interrumpe la conversación.
La pantalla. Al tocar el botón se abre el catálogo entero: las secciones como chips arriba, una grilla de productos, y cada producto con su propia ficha donde se elige la cantidad.
La canasta. Vive en el teléfono, por chat y por agente. No es del servidor: es de esa persona en esa conversación.
El pedido. Cuando toca enviar, todo sale como un solo mensaje, no como quince. Eso importa más de lo que parece: quince mensajes de "agregué esto" hacen ilegible un grupo.
Por qué la canasta va del lado del cliente
Es la decisión de diseño que más consultas genera.
Si la canasta viviera en tu servidor, cada toque de "+" sería una llamada. La persona agrega doce productos y son doce viajes de ida y vuelta, con la latencia de cada uno.
Del lado del cliente, agregar y sacar es instantáneo, y tu servidor se entera una sola vez: cuando el pedido sale. Es también lo que hace que funcione bien con señal mala.
La pastilla de arriba
Un catálogo sin estado visible es incómodo: la persona no sabe qué lleva acumulado.
Por eso el carrito se fija arriba del chat, con la cantidad y el total, y tu agente lo actualiza cada vez que lo toca. Un toque y se abre. Cuando queda vacío, desaparece.
Esa pastilla no es sólo para carritos: sirve para cualquier estado que quieras dejar a mano. Un pedido en camino, un turno, una guardia.
Las palabras las ponés vos
El componente no dice "comprar" en ningún lado. El rótulo, el nombre de la canasta, el texto del botón de enviar y el de confirmación vienen de vos.
Por eso el mismo componente sirve para un supermercado, para un inventario interno donde el equipo "pide" repuestos, o para reservar turnos. Lo que cambia es el vocabulario, no el código.
Qué más tenés para no mandar a nadie a una web
- Botones, para un sí o un no.
- Listas, de una opción o varias, con secciones.
- Formularios de hasta ocho campos, con respuestas guardadas arriba: las direcciones que esa persona ya usó aparecen como filas para tocar, y recién debajo los campos vacíos.
- Pedir la ubicación, una foto o un archivo. La respuesta llega como el mensaje de la persona con ese adjunto, más la referencia de a qué botón contestó.
Todo eso lo devolvés desde una herramienta de tu servidor MCP, y el modelo lee la tarjeta como texto, así que sabe qué le ofreció.
Y cuando pasa algo después
El pedido salió, pero falta avisar que se despachó.
Para eso, cada llamada a tu servidor trae una dirección para publicar en ese chat. La guardás y hacés un POST cuando tengas la novedad, sin que nadie escriba nada. Está explicado en la nota de MCP.
El detalle de cada campo, en la documentación.