En resumen: vender a empresas, oficinas o revendedores es un canal que cierra en el papel y se traba en la operación: pedidos por WhatsApp, una planilla que alguien consolida, cobranza persona por persona y nadie sabe qué preparar hasta el último día. Una app de pedidos propia resuelve eso con roles para cada parte, un ciclo con fechas, cobro sin perseguir a nadie, el consolidado armado solo y la conexión con tu sistema de stock. Lo que no tiene que hacer es reemplazar lo que ya funciona.
El canal que cierra en el papel y se traba en la operación
Una marca que vende bien de a una persona mira a las empresas y ve un canal obvio: en vez de cien clientes sueltos, una oficina con cien empleados que piden todos juntos y reciben todo junto. El margen cierra, la logística cierra, el modelo cierra.
Lo que no cierra es la operación. Los pedidos llegan por WhatsApp, de a uno. Alguien de Recursos Humanos del cliente junta todo en una planilla. Hay que cobrarle a cada persona por separado, o pedirle a la empresa que adelante la plata. Y hasta el último día nadie sabe qué hay que preparar. Ese trabajo manual crece con cada empresa nueva, y es exactamente lo que impide abrir el canal.
KUKUI, una marca de frutos secos y alimentos saludables, llegó con ese problema. Lo que sigue sale de cómo se resolvió.
Qué tiene que resolver la app
Roles distintos sobre el mismo producto
Una tienda online tiene un rol: el comprador. Vender a empresas tiene por lo menos tres.
- La persona que pide. Entra con el código de su empresa una vez, queda con cuenta propia, arma su pedido y paga lo suyo. Tiene que poder repetir el último pedido en un clic o dejarlo recurrente.
- El referente de la empresa. Ve el estado del ciclo de su oficina: qué se pidió, cuánto lleva el equipo, cuándo cierra. No ve nada de otras empresas.
- Tu backoffice. El consolidado de cada empresa listo para preparar, el catálogo y el alta de empresas clientes. Sin tocar una planilla.
Si la empresa cliente además revende, aparece un cuarto rol con su propia lógica: una bonificación por escalones que sube con lo que entra en el mes, visible en su panel.
Un ciclo con fechas, no un carrito abierto
La diferencia de fondo con una tienda es el tiempo. Una tienda vende cuando alguien quiere comprar; una venta a empresas se organiza por ciclo: cada empresa tiene su fecha de apertura, su cierre de pedidos y su día de entrega. Antes de la apertura no se toman pedidos. Cuando cierra, el consolidado queda armado. Ese ciclo es el motor de la app, y todo lo demás cuelga de él.
Cobro sin perseguir a nadie
Hay dos modelos, y conviene elegir uno antes de construir. O paga cada persona lo suyo, con una pasarela como Mercado Pago integrada en el pedido, y nadie junta plata en la oficina. O paga la empresa, y la app arma el consolidado que después se factura. En el caso de KUKUI se eligió el cobro individual, y se descartó a propósito que la empresa subsidie una parte: sumaba complejidad al cobro y no sumaba ventas.
Un detalle que no se ve hasta que falla: si el pago no se completa, el pedido no puede quedar "de fantasma", medio hecho. La app tiene que resolver ese caso.
El consolidado armado solo
Es la razón de todo. El día del cierre, tu equipo abre el backoffice y encuentra la lista de preparación por producto y el detalle por persona, listos para bajar. Lo que antes era una tarde de planilla, con errores, deja de existir.
Conexión con tu sistema de stock, no reemplazo
Si ya llevás stock y facturación en un ERP, la app no tiene que reemplazarlo ni obligarte a cargar los pedidos dos veces. Tiene que hablar su idioma: los mismos códigos de producto, las fotos cruzadas por ese código, y el consolidado exportado en el formato que el ERP importa, con la lista de precios y el vendedor que ya usás. En KUKUI eso fue Odoo, y fue la última pieza del circuito.
Avisos y cuentas que se administran solas
Confirmación, cierre, entrega y comprobante por correo, generados por la app. Recuperación de contraseña sin pedirle nada a tu equipo. Cada cosa que la gente resuelve sola es un mensaje de WhatsApp que no te llega.
En qué orden construirla
El orden importa tanto como el producto, y el de KUKUI sirve de referencia:
- Demo navegable primero. Catálogo, carrito, "mis pedidos" y la vista de la marca, con datos simulados y sin backend. Estuvo en un día y fue lo que se mostró en las reuniones para confirmar el modelo. El cliente vio funcionando lo que iba a comprar antes de pagar por construirlo.
- Backend real. Base de datos, precios reales, pedidos guardados. Con el modelo confirmado.
- Cuentas y avisos. Acceso por código de empresa, correo confirmado, los avisos de cada pedido.
- Cobro de verdad. La pasarela integrada y los casos de error cubiertos.
- Cierre con el ERP. Fotos y códigos cruzados, exportación de cada mes en el formato del sistema.
Entre la demo y el circuito cerrado pasaron poco menos de cuatro meses, con la app publicada y en uso desde el segundo. El caso cuenta cada paso con su fecha.
Qué dejar afuera a propósito
- Todo pago que no pase por la app. Transferencias y efectivo obligan a conciliar a mano. Si entran, la planilla vuelve.
- Un panel con más funciones para el cliente. El referente de la empresa ve su ciclo y nada más. Lo que no se usa no se mantiene.
- Reemplazar el ERP. Ya está dicho, pero es la tentación más cara.
Si hoy ese canal te lo sostiene una planilla, acá están las siete señales de que llegó el momento de un sistema propio. Y si dudás entre armarlo con una herramienta sin código o a medida, esta guía compara las dos.
Cómo lo hacemos en V3XRA
Una app de pedidos en V3XRA arranca con el diagnóstico, que no se cobra: cómo vendés hoy, quién pide, quién paga y con qué sistema hay que convivir. Después, el prototipo navegable antes del backend, una entrega usable cada dos semanas y el traspaso con el código a nombre de tu empresa. Está todo en desarrollo de apps a medida.
Preguntas frecuentes
Sirve para vender de a una persona. Vender a una empresa tiene reglas que una tienda no contempla: varias personas piden bajo una misma cuenta, hay fechas de cierre y de entrega, el cobro puede ser individual o centralizado, y alguien del lado del cliente necesita ver el estado del pedido de todo su equipo. Eso es lo que resuelve una app de pedidos propia.
Depende del modelo. Si cada persona paga lo suyo, se integra una pasarela como Mercado Pago y nadie persigue transferencias. Si paga la empresa, la app arma el consolidado y la factura sale por tu sistema habitual. En el trabajo publicado de KUKUI se eligió el cobro individual por Mercado Pago, y se descartó a propósito que la empresa subsidie.
No debería. Si ya llevás stock y facturación en un ERP como Odoo, la app tiene que exportar los pedidos en el formato que ese sistema importa, con los mismos códigos de producto. Reemplazar el ERP por la app, o cargar los pedidos dos veces, es cambiar una planilla por otra.
En el caso publicado, la demo navegable estuvo en un día, el backend real seis semanas después de confirmado el modelo, y el circuito completo con cobro y conexión con el ERP en menos de cuatro meses, con la app ya publicada y en uso desde el segundo mes. El plazo de tu proyecto sale escrito del diagnóstico, que no se cobra.