VCommerce
Ecommerce B2B/B2C + agente de atención y venta
Plataforma white label para fabricantes, distribuidores y mayoristas que venden por bulto y por pallet. Tienda y backoffice en producción, un agente de IA que atiende sin inventar precios, y el ERP de la empresa como sistema de registro. Tres niveles, una sola base de código.
El problema que resuelve
El precio vive en el ERP; la web dice otro
Catálogo, listas y clientes están en el sistema de la empresa. La tienda, cuando existe, se carga a mano y queda desfasada. Dos pantallas, dos precios.
La venta mayorista pasa por WhatsApp y Excel
Cotizaciones a mano, escalones por volumen que cada vendedor aplica distinto, pedidos que se tipean dos veces. Sin trazabilidad de quién prometió qué.
Atender lo repetido consume a ventas
«¿Cuánto trae el bolsón?», «¿llegan a mi zona?», «¿cómo compro?». Las mismas preguntas, todos los días, en horario comercial y fuera de él.
Tres niveles, una sola base
Cada nivel incluye al anterior. Se activa por configuración y por adaptadores, no se reescribe: pasar de N1 a N2 o a N3 es sumar módulos sobre lo que ya está en producción. Elegí un nivel para ver qué incluye.
Tienda · dominio público · compra sin registro
- Catálogo por secciones con ficha por producto, atributos técnicos, imágenes y buscador.
- Precios por escalón —lista, pallet y precio por cantidad— resueltos siempre en el servidor y publicados sin ambigüedad.
- Proforma / carrito cotizada por línea; mínimos y umbrales configurables desde el backoffice.
- Checkout con dirección geocodificada, zona de entrega por polígono y fecha prometida en días hábiles.
- Cliente reconocido por CUIT o número de cliente: no vuelve a cargar sus datos.
- SEO y landings mayoristas; datos estructurados sin precios.
Backoffice · login corporativo · roles · auditoría
- Catálogo y publicación por canal (consumidor / empresa), alta y baja lógica, orden de vidriera.
- Precios versionados: cada publicación es atómica y el pedido congela la versión con la que se cerró.
- Pedidos con máquina de estados, bandeja, ficha y reintento de avisos.
- Usuarios y matriz de permisos en tres capas —menú, página, endpoint— con auditoría en cada cambio.
- Avisos de pedido nuevo por mail (con PDF) y WhatsApp; resumen diario a las 7.
- Panel con rankings de 30 días por vendedor, producto y cliente.
Todo el nivel 1, más el agente
- Atiende en la tienda: responde sobre productos, medidas, presentaciones, zonas de entrega y cómo comprar, siempre con enlace a la ficha.
- Guía la compra: busca por metraje o por uso, ordena por más vendidos y deriva a ventas cuando corresponde (formulario que crea un lead y avisa por mail y WhatsApp).
- Trabaja en el backoffice: tres modos —«como cliente», Ventas y Dirección— con consultas internas: pedidos, conversaciones, productos con precio.
- Aprende con aprobación: ventas propone la respuesta correcta («Entrenar»), dirección la aprueba y recién ahí modifica la memoria.
- Se mide: conversaciones y costo por día en el resumen de las 7; «preguntas de oro» en cada despliegue.
- Leads y conversaciones visibles en el backoffice, con el hilo completo.
Todo el nivel 2, más el ERP como sistema de registro
- Réplica de artículos, precios y clientes desde el ERP cada 2 horas o a mano desde el backoffice.
- El ERP gana en las diferencias; lo que el negocio corrige en el backoffice se bloquea campo por campo y el sync no lo pisa.
- Artículos nuevos nacen sin publicar y con alta incompleta hasta cargar lo que el ERP no trae (sección, alícuota, medidas, fotos).
- «Enviar al ERP»: el pedido vuelve con el precio que el cliente aprobó; si el comprador no está en el ERP, queda pendiente y ventas recibe un WhatsApp.
- Salud de la integración: cada llamada registrada; el panel dice si está operativa, intermitente o caída, y desde cuándo. La caída avisa.
- Precios tienda contra ERP comparados al abrir el panel, producto por producto.
| Capacidad | N1 Ecommerce | N2 + Agente | N3 + ERP |
|---|---|---|---|
| Tienda pública: catálogo, ficha, proforma, checkout | ■ | ■ | ■ |
| Backoffice: catálogo, precios versionados, pedidos, usuarios, permisos, auditoría | ■ | ■ | ■ |
| Zonas de entrega por polígono y fecha prometida | ■ | ■ | ■ |
| Avisos por mail y WhatsApp · resumen diario | ■ | ■ | ■ |
| SEO, landings y analytics | ■ | ■ | ■ |
| Agente de IA en la tienda (consultas, guía de compra, derivación) | — | ■ | ■ |
| Agente en el backoffice (modos Ventas / Dirección, entrenamiento aprobado) | — | ■ | ■ |
| Leads y conversaciones en el backoffice | — | ■ | ■ |
| Réplica de artículos, precios y clientes desde el ERP | — | — | ■ |
| «Enviar al ERP» · cliente del ERP en el checkout | — | — | ■ |
| Salud de la integración · precios tienda contra ERP | — | — | ■ |
| Canales WhatsApp y voz para el agente | hoja de ruta | hoja de ruta | hoja de ruta |
El agente: guardarraíles por diseño, no por prompt
Un servicio aparte, en Python con LangGraph, que sólo afirma lo que una herramienta respalda: consulta la API pública de la tienda y una memoria curada de la empresa. No importa el dominio ni la base de datos; habla por HTTP, y eso es parte de la seguridad.
Conexión con el ERP o sistemas propios
Qué resuelve
- El ERP es el sistema de registro. La tienda es una réplica con fecha: muestra el precio del ERP y nunca uno propio.
- El ERP gana en las diferencias; lo que el negocio corrige en el backoffice se bloquea campo por campo y el sync no lo pisa.
- Artículos nuevos nacen sin publicar hasta cargar lo que el ERP no trae: sección, alícuota, medidas, fotos.
- El pedido vuelve al ERP con el precio que el cliente aprobó; si el comprador no existe en el ERP, queda pendiente y ventas recibe un WhatsApp.
Control operativo
- Salud de la integración: cada llamada al ERP registrada con resultado y duración; el panel dice si está operativa, intermitente o caída, y desde cuándo. La caída avisa.
- Precios tienda contra ERP comparados al abrir el panel; un producto publicado sin vínculo al ERP es error del sync.
- Variaciones grandes se destacan sin frenar la corrida; corridas duplicadas se deduplican por evento.
- Un adaptador por ERP. El dominio no cambia: cambia cómo se lee y se escribe.
Arquitectura
Stack
Turborepo · Next.js 15 (App Router) · TypeScript strict · Zod · Prisma 6 · PostgreSQL 16 / PostGIS · Auth.js v5 · TanStack Query · Tailwind · Vitest + Playwright · Python 3.12 + LangGraph · Terraform · AWS · Twilio WhatsApp.
Principios que vienen de serie
- El precio lo resuelve el servidor. Un pedido con precio en el body se rechaza. Dos pantallas no pueden decir dos precios de la misma cosa.
- Los precios del pedido son snapshot. Se congela la versión con la que el cliente aprobó.
- El estado sólo lo escribe la máquina de estados. Transiciones válidas en un único lugar, testeadas.
- Permisos en tres capas + auditoría. Un test falla si una pantalla nueva no declara su permiso.
- Webhooks idempotentes y firmados. Pagos, WhatsApp y mail validan firma y registran por referencia del proveedor.
- Sin PII en los logs. Email, CUIT, teléfono, dirección y pagos nunca llegan a un log.
- Migraciones compatibles hacia atrás. Durante un despliegue conviven dos versiones del código.
- Cobertura > 80 % en el dominio. Pricing y pedidos no son negociables; E2E en los flujos críticos.
Caso de referencia: fábrica de papel tissue, Argentina
Lo que había
Una fábrica industrial que vendía por bolsón y pallet a comercios y distribuidores, con catálogo y precios en su ERP, cotizaciones por WhatsApp y una presencia web que no vendía. Ventas atendía lo mismo todos los días.
Lo que hay
Tienda y backoffice en producción, el ERP como sistema de registro (artículos, precios y clientes replicados; el pedido vuelve al ERP con un clic), un agente que atiende en la tienda y en el backoffice sin decir nunca un precio, y un panel que compara lo que cobra la tienda contra el ERP cada vez que se abre.
Ejemplos en producción
Tres sitios distintos sobre la misma base: una fábrica industrial, un servicio de impresión 3D y una panadería. Cambian la marca, el catálogo y las reglas; no cambian las garantías.
New Pel
Fábrica de papel tissue. Venta mayorista por bolsón y pallet desde 50 bolsones surtidos, proforma, checkout con zona de entrega, asistente «Laia» y el ERP como sistema de registro. Es el caso de referencia de la sección 06.
VittoLabs
Servicio de impresión 3D. Buscador unificado sobre MakerWorld, Cults3D y Printables, cotización estimada al instante y pedidos sin registro, con entrega en zona sur y CABA y envíos al interior.
Casa Vittori
Panadería italiana y pizzería napolitana en Hudson. Pan de masa madre, focaccia y pizza, con suscripción mensual de pan y catering para eventos privados.
White label: qué se adapta y qué no se toca
Se adapta a cada cliente
- Marca: tokens de color, tipografía y logo del brandbook del cliente en el design system; dominio y subdominio propios.
- Catálogo: secciones, atributos técnicos, unidades de venta (unidad, paquete, bulto, pallet) y cómo se nombran en pantalla.
- Reglas de negocio por configuración: mínimos de pedido, escalones, radio de envío gratis, plazo prometido, feriados, umbrales de aprobación.
- El asistente: nombre, identidad visual, tono, base de conocimiento y guion de derivación.
- Canales y avisos: destinatarios, plantillas de WhatsApp y mail, horario del resumen diario.
- Integraciones: adaptador del ERP, pasarela de pagos, facturación electrónica, logística.
No se toca: las garantías del producto
- Resolución de precios en el servidor y snapshot en el pedido.
- Máquina de estados del pedido y aprobaciones por umbral.
- Aislamiento por cliente: toda lectura filtra por la sesión; los endpoints que ven todo viven en el backoffice.
- Guardarraíles del agente: sin importes, sin afirmaciones sin herramienta, servicio aislado.
- Auditoría, permisos, idempotencia de webhooks y logs sin datos personales.
- Separación tienda / backoffice en infraestructura e identidad.
Plazos estimados y costos operativos
Plazo de implementación (semanas, desde la definición hasta producción)
■ mínimo estimado · □ rango. Estimaciones sobre el caso de referencia. Los niveles se pueden contratar por separado o en secuencia; N2 y N3 suman sobre N1. El N3 depende de la API del ERP.
Cloud propia o del cliente. Escala con el tráfico; sin piezas caras hasta que hagan falta.
Costo visible por día en el resumen; tope por mensaje y presupuesto mensual configurable.
Avisos internos y plantillas aprobadas; sin opt-in no hay mensaje.
Por nivel y alcance, tras una reunión de diagnóstico. Incluye la adaptación white label.
Cómo lo construimos: agentes de noche, criterio de día
Qué hacen las personas
- Definen la intención: qué se vende, cómo se cobra, qué se promete. Eso no lo decide un modelo.
- Auditan lo construido: cada paso del pipeline pide confirmación; las devoluciones de ventas entran como PRDs con bitácora.
- Aprueban lo que el agente aprende: ventas propone, dirección aprueba.
Qué gana el cliente
- Velocidad con trazabilidad: cambios en días, cada decisión documentada en el repositorio.
- Un producto, no un proyecto: lo que mejora para un cliente mejora la base de todos, sin mezclar datos ni marca.
- Código propio y legible: TypeScript estricto, convenciones explícitas, sin dependencia de una caja negra.
Empezamos por un diagnóstico
Una reunión de trabajo: canales de venta, catálogo, ERP y cómo cotizan hoy. Salida: el nivel recomendado, los supuestos y una propuesta con alcance, plazos y costos.
¿Preferís el mail? Escribinos a info@vittori.me.