WhatsApp como canal de onboarding: aprendizajes con Toshify

Por qué WhatsApp y no otra cosa

Toshify acompaña a los choferes que quieren unirse a Cabify: apertura de cuenta, verificación documental, toma de contacto con la app, activación. El brief inicial mencionaba un sitio web. Nuestra auditoría mostró tres cosas.

Primero, el 95% de los candidatos son choferes ya activos (taxi, VTC, plataformas competidoras) que quieren un trámite rápido entre dos carreras. No abren un navegador en su smartphone — abren WhatsApp.

Segundo, el operador histórico del onboarding (3 FTE al teléfono) topaba al 60% de candidatos llamados en menos de 24 h. No por incompetencia, por restricción horaria. Un canal asíncrono resuelve eso.

Tercero, la API de WhatsApp Business es madura, conforme RGPD, y utilizable en producción sin parches.

La stack

Elegimos piezas probadas: WhatsApp Business API oficial (vía Twilio), backend Node.js, orquestación n8n, LLM Gemini con una base de conocimiento documental (RAG estricto), y push hacia Intercom, Supabase y nuestra herramienta interna para la transmisión al servicio comercial.

Sin agente autónomo multi-etapa, sin memoria vectorial compleja, sin modelo local. La stack es deliberadamente simple — eso es lo que la hace mantenible. Detalles en nuestro servicio de Chatbots IA.

Tres salvaguardas críticas contra las alucinaciones

Cuando tu agente habla en nombre de una marca (Toshify) que a su vez habla en nombre de una plataforma tercera (Cabify), una sola respuesta errónea puede generar un litigio. Tres salvaguardas son sistemáticas.

Salvaguarda 1 — RAG estricto. El agente solo responde a partir de la base documental proporcionada por Toshify (política chofer, condiciones Cabify, trámites administrativos). Si la pregunta sale de esa base, deriva.

Salvaguarda 2 — Umbral de confianza. El LLM produce una probabilidad de pertinencia de la respuesta. Por debajo de 0,85, derivación humana automática. Mejor derivar un caso fácil que alucinar.

Salvaguarda 3 — Prompt de sistema anti-especulación. El prompt contiene explícitamente: «Si no estás seguro, di “derivo tu pregunta a un supervisor”. Nunca adivines». Es prompt engineering básico pero crítico.

Resultado: cero alucinaciones reportadas por Toshify en 8 meses de producción. No porque el modelo sea perfecto, sino porque las salvaguardas le impiden divagar fuera del tema.

Las derivaciones inteligentes: cuándo intervenir

La trampa clásica de un chatbot: tratar todo o derivar todo. El buen diseño está en medio.

Identificamos cuatro disparadores de derivación: (1) la pregunta sale del perímetro cubierto por la base de conocimiento, (2) el candidato expresa frustración (detectada por clasificación LLM), (3) el perfil corresponde a un caso premium o litigioso (campos CRM), (4) el candidato pide explícitamente hablar con un humano.

A escala, el 95% de los candidatos se atienden en autonomía completa, y el 5% se derivan al supervisor. El equipo Toshify hace funcionar a un solo supervisor en supervisión activa, contra tres FTE antes. Mira el detalle en el caso Toshify.

RGPD y cumplimiento (no saltarse esto)

WhatsApp Business API es, sobre el papel, conforme RGPD. Pero eso no exime de poner unas bases.

Opt-in explícito: el candidato debe haber dado su consentimiento antes de que le escribas. Que el propio candidato abra la conversación (vía QR o enlace) basta técnicamente.

Conservación de datos: fijamos una retención de 12 meses para las conversaciones, 24 meses para los datos de cualificación en el CRM. Más allá, eliminación automática.

Hosting: transcripciones y datos estructurados almacenados en Europa (Francia). Eso cuenta más allá del RGPD: tranquiliza las auditorías de seguridad del lado de Cabify.

Argentina: la ley 25.326 está ampliamente alineada con el RGPD. Hicimos validar la solución por un abogado local antes de la puesta en producción.

Lo que haríamos diferente

Primer arrepentimiento: subestimamos la diversidad del español. El español argentino (Río de la Plata) tiene voseo y un léxico distinto del ibérico o el colombiano. Nuestros primeros prompts sonaban ibéricos. Reescribimos el prompt de sistema para integrar el tono local, pero hubiera sido más simple anticiparlo.

Segundo arrepentimiento: habríamos dedicado más tiempo a encuadrar las derivaciones. Al inicio, subestimamos algunos casos atípicos (chofer que ya tuvo un incidente en otra plataforma, por ejemplo). Añadimos esas reglas sobre la marcha, pero medio día más de auditoría en el encuadre habría evitado 2-3 iteraciones.

Tercer arrepentimiento: ninguno. WhatsApp era el canal correcto, la stack era la correcta, las salvaguardas resistieron. Eso es raro.