perla update interno · 29/05

Tomi conectó el agente al dashboard.

El sprint del 28/05 cerró la pieza que faltaba para que Perla sirva a varios negocios desde un mismo número de WhatsApp. Acá un resumen narrativo de qué se decidió, qué cambia para el equipo y qué viene.

El cambio en una frase

Hasta ayer, Perla solo podía manejar un negocio por vez — todo el código asumía que cualquier mensaje entrante era del negocio piloto. Desde ayer, Perla puede recibir mensajes de cualquier cantidad de negocios sobre el mismo número de WhatsApp, identificando a cada uno por el código que el cliente trae en el primer mensaje (o por su historial previo si ya escribió antes).

Es la transición del "MVP atado a un solo negocio" al "plataforma multi-negocio de verdad". Es lo que abre toda la fase comercial de Perla.

Cómo funciona ahora, en castellano

El número es uno solo, para todos

Hay un único número de WhatsApp Perla. Cuando un cliente escribe, Perla mira el mensaje para saber a qué negocio se está dirigiendo. No hace falta tener un número por cada negocio.

Cada negocio tiene un código corto

Por ejemplo, una peluquería podría tener el código STYLE17. El link que comparte ese negocio en sus redes ya incluye el código en el mensaje: "Hola, te escribo por Style #STYLE17". El cliente clickea, manda ese mensaje prellenado, Perla lo lee y sabe inmediatamente con qué negocio quiere hablar.

Si el cliente vuelve sin código, Perla no se pierde

Cuando alguien ya conversó con Perla antes y vuelve a escribir días después sin el código, Perla mira su historial. Si solo conversó con un negocio, sigue ahí; si conversó con varios, le pregunta cuál. Si no tiene historial, le pregunta directamente con qué negocio quiere comunicarse.

Las decisiones finas que tomó Tomi

Detrás del cambio grande hay ocho decisiones más sutiles que muestran que pensó el flujo real, no solo el caso ideal. Vale leerlas para entender cómo se va a comportar Perla cuando aparezcan los casos raros.

01

Un solo canal de WhatsApp para todos los negocios

Antes, el sistema esperaba un canal por negocio. Ahora hay un canal compartido a nivel plataforma, y el negocio se identifica adentro del mensaje. Más simple operacionalmente, más barato técnicamente.

02

Tres formas de identificar al negocio, no una sola

Tomi implementó las tres rutas del canon: código en el mensaje, historial previo con confirmación, pregunta directa con disambig. No tomó el atajo de "solo código" porque eso dejaba al cliente recurrente colgado.

03

Sala de espera para mensajes sin negocio resuelto

Si llega un mensaje y todavía no se sabe a qué negocio pertenece, va a una tabla aparte (no se mete a la base "real" del negocio piloto por defecto). Cuando se resuelve el negocio, recién ahí se promueve al inbox correcto. Mantiene los datos limpios entre negocios.

04

Una vez que hay conversación, no vuelve a preguntar

Si el cliente ya está en una conversación activa con un negocio, los mensajes siguientes sin código siguen ahí sin interrumpir. Perla no pregunta "¿seguimos con X?" a mitad de la charla. Detalle de respeto al usuario.

05

Cambio de negocio a mitad de conversación, solo cambia el mensaje actual

Si un cliente está hablando con un negocio y de repente manda un código nuevo (de otro negocio), Perla rutea ese mensaje al nuevo negocio pero NO arrastra los mensajes anteriores. Evita que un intent que era para un negocio termine en otro.

06

El número compartido puede mandar mensajes en nombre de cualquier negocio

Las respuestas que el agente o el dueño manden salen por el número compartido aunque el negocio en sí no lo "posea". La frontera del negocio queda dentro del thread y los mensajes, no en el número.

07

Si un negocio cambia su código, el viejo sigue funcionando 90 días

Importante para QR impresos en locales o links viejos circulando: si el negocio cambia su código de STYLE17 a STYLE2026, el viejo sigue resolviendo al mismo negocio durante 90 días, y otro negocio no puede agarrar ese código mientras tanto.

08

Si llega una foto sin negocio identificado, Perla pide el código por texto

Si alguien manda una imagen o un audio antes de que Perla sepa con qué negocio está hablando, le pide que mande primero el código por texto. No guarda la media en el inbox de ningún negocio hasta resolver.

Qué viene

El código ya está mergeado a main y deployado en staging. Para que el cambio se active de verdad falta una secuencia operativa corta del lado de la plataforma:

  1. Cargar los tokens de WhatsApp en el entorno staging de Cloudflare (los que Tomi compartió por canal seguro).
  2. Asignar un código corto al negocio piloto en la base de datos (por ejemplo PERLA01) + corregir el número visible que estaba desactualizado.
  3. Reapuntar el webhook de Meta al endpoint nuevo (la URL compartida sin código de negocio en el path).
  4. Probar con WhatsApp real los ocho casos del runbook (mensaje con código, sin código, media, multi-conversación, etc).
Una vez completada esta secuencia, Tomi y Fede pueden empezar a probar la conversación entera desde la pantalla /app/messages del dashboard, sin que dependa de la máquina de Seba. Es lo que se desbloquea con este sprint.

Cómo se entera el equipo

Las cuatro tareas operativas de arriba ya están sembradas como sub-tareas en el frente Módulo Agente del Centro de Mando, cada una con su capability, paso a paso, criterio de validación y referencias técnicas. La auditoría completa del sprint también quedó como tarea Completada en el mismo frente.

Cualquier duda sobre el flujo, los detalles técnicos están en la documentación que Tomi escribió junto con el código (referencias abajo).

Referencias técnicas

Para Tomi, Guido, Nico — todo lo que necesitan para entender qué se mergeó:

— Designed by humans · Built by intelligence