Hoja de ruta — Repuestos Cueva

Reunión de arranque. Sin esto cerrado, no se empieza: cada punto pendiente acá se convierte en una semana de atraso después.

• Confirmar quién es el responsable del lado del cliente — una persona que consiga accesos y destrabe. En este caso, Marlon.
• Definir quién va a actualizar el catálogo cuando el sistema esté vivo. Si nadie tiene ese rol asignado, el proyecto muere a los dos meses.
• Conseguir el RUC y datos de la empresa para las altas a nombre del negocio.
• Decidir el número de WhatsApp: uno nuevo, o migrar el actual. Migrar significa que el vendedor pierde ese número en su celular.
• Acordar la ventana de corte: a partir de qué fecha el Excel deja de ser la fuente de verdad.

Se hace el primer día, antes que cualquier otra cosa, porque el tiempo lo pone Meta y no se puede comprimir.

• Crear la cuenta de Meta Business a nombre de Repuestos Cueva (no a nombre personal de nadie).
• Verificar el negocio: Meta pide documentación de la empresa. Con RUC y un recibo de servicios a nombre del negocio suele alcanzar.
• Elegir el proveedor de la API. Meta Cloud API directo es la opción más barata; los intermediarios cobran más pero simplifican el alta.
• Registrar el número. Si es un número que ya está en WhatsApp normal, hay que desvincularlo primero — no puede estar en los dos a la vez.
• Cargar la plantilla de mensaje de bienvenida para aprobación (Meta revisa los mensajes iniciales).

Todo se da de alta con el correo del cliente, no con el nuestro. Nosotros pedimos acceso como colaboradores. Así, el día que el cliente quiera seguir por su cuenta, no hay nada que transferir.

• Crear la cuenta de Cloudflare con el correo del negocio. Plan gratuito para empezar; se sube a pago solo si el volumen lo pide.
• Registrar o apuntar el dominio. Si ya tienen uno, se agrega a Cloudflare y se cambian los nameservers.
• Crear la base de datos D1 donde vivirá el catálogo.
• Crear el bucket R2 para los respaldos automáticos.
• Guardar todas las credenciales en un gestor de contraseñas del negocio — no en un chat, no en un Excel.

Es el paso más largo, el más aburrido y el que decide si el proyecto funciona. Un bot con datos sucios es peor que no tener bot: responde con seguridad cosas que son falsas.

Del Excel actual hay que llegar a una tabla con estas columnas mínimas:

Recomendación de método: no intentar migrar los 14 años de una vez. Empezar por los 200 productos más vendidos, que suelen ser el 80% de las consultas. El resto se carga después, con el sistema ya funcionando.

Mientras el cliente limpia datos, se construye dónde van a vivir.

• Esquema de la base con la tabla de productos y un índice de búsqueda por aplicación.
• Buscador tolerante a errores: tiene que encontrar “yaris” escribiendo “llaris”, y “distribución” escribiendo “distribucion”. Los clientes escriben rápido y con faltas.
• Panel web para que el almacenero actualice stock y precios desde el celular.
• Importador de Excel, para la carga inicial y las masivas.
• Respaldo automático diario a R2.

Recién acá aparece el bot, y es la parte más rápida — porque lo difícil ya está hecho: los datos.

• Conectar el webhook de WhatsApp al Worker.
• Definir el contexto del negocio: horario, formas de pago, dirección, tono, qué puede prometer y qué no.
• Conectar la búsqueda: cuando alguien pregunta por una pieza, el bot consulta el catálogo real. No inventa. Si no encuentra, lo dice.
• Reglas de escalamiento: pedido mayor a cierto monto, reclamo, o cualquier cosa que el bot no resuelva en dos intentos, pasa a una persona con aviso.
• Horario de atención: fuera de horario responde igual, pero avisa cuándo alguien va a confirmar.

El sistema ya existe; ahora se llena y se prueba con la realidad.

• Importar el catálogo limpio. Revisar los rechazos del importador uno por uno — suelen ser precios con texto o stock vacío.
• Prueba con consultas reales: tomar las últimas 50 conversaciones del WhatsApp actual y pasarlas por el bot. Es la mejor prueba que existe, porque son las preguntas que de verdad hacen sus clientes.
• Medir cuántas resuelve solo, cuántas escala y cuántas responde mal. La tercera categoría es la única que importa: cada error se corrige antes de salir.
• Piloto en paralelo: una semana con el bot atendiendo y un vendedor revisando cada respuesta antes de que salga. Cuando ya no haya correcciones, se suelta.

El proyecto no termina cuando el bot funciona, sino cuando el equipo lo opera sin nosotros.

• Sesión con los vendedores: cómo consultar el catálogo desde el mostrador, cómo tomar una conversación que el bot escaló.
• Sesión con el almacenero: cómo actualizar stock, precios y ubicaciones. Es el rol más crítico para que el sistema no se degrade.
• Sesión con Marlon: cómo leer las métricas, cómo cambiar el horario o el mensaje de bienvenida.
• Entrega del manual de operación: qué hacer si el bot deja de responder, a quién escribir, cómo revertir una carga masiva mal hecha.
• Transferencia formal de credenciales y confirmación de que todo está a nombre del negocio.

Lo que tiene que pasar todas las semanas para que esto siga sirviendo dentro de un año.

• Diario: el almacenero actualiza stock de lo que entra y sale. Cinco minutos.
• Semanal: Marlon revisa las conversaciones que el bot escaló. Ahí aparecen los productos que faltan cargar y las preguntas que no sabe responder.
• Mensual: revisar cuántas consultas resolvió solo. Si el número baja, el catálogo se está quedando desactualizado.
• Trimestral: mantenimiento de Kallpa — revisión de errores, ajuste del asistente con lo aprendido, actualización de dependencias.