#28 DataInbox no nació en una pizarra. Nació de un cliente real con un problema real
Antes de escribir la primera línea de DataInbox, no tenía un producto. Tenía una conversación.
Un cliente y amigo, con más de 25 trabajadores, me dejó entrar en su empresa a mirar cómo trabajaban de verdad. No a venderle nada. A ver.
Y lo que vi fue lo que ya conté en otro artículo: comerciales abriendo Outlook y WhatsApp cada mañana, interpretando pedidos que llegaban en diferentes formatos (PDF, imágenes, texto escrito de cualquier manera,...), copiando referencias a mano en el ERP, pedido a pedido, 7 minutos de media cada vez.
Nadie me pidió "hazme una IA que lea emails". Me enseñaron una bandeja de entrada llena de trabajo mecánico y una persona dedicando gran parte de su jornada a hacer esto.
Lo fácil hubiera sido construir primero
Podría haberme sentado a programar directamente, dejándome llevar por lo que yo pensaba que necesitaban.
Total, a priori, la idea parecía clara: automatizar la entrada de pedidos.
Pero eso es exactamente lo que veo hacer cada semana a mucha gente que lanza un SaaS nuevo. Construyen desde la comodidad de su mesa lo que "seguro que todo el mundo necesita". Y después salen a buscar quién lo compre.
El problema es el orden. Construir es fácil. Vender ese software a una empresa real, que lo pague y lo use cada día, sigue siendo tan difícil como siempre. La mayoría de esos productos no llegan a cinco clientes en toda su vida. No por el código. Porque nadie los pidió.
DataInbox nació al revés
Yo no partí de una idea. Partí de una necesidad ya validada, contada por quien la sufría cada día.
Eso cambió todo lo que construí después. Qué debía leer el sistema primero (email, WhatsApp, PDF, imagen). Qué interpretación necesitaba de verdad la persona detrás del pedido. Qué parte del proceso podía automatizarse sin romper la validación humana donde hacía falta.
Nada de eso lo hubiera acertado a la primera pensando solo. Lo acerté porque ya sabía, antes de escribir código, exactamente qué problema tenía que resolver, y no otro.
Lo que cambió después
Hoy, en esa misma empresa, más de la mitad de los pedidos se procesan de forma totalmente automática. Los comerciales han dejado de perder minutos interpretando fotos de cajas y mensajes ambiguos.
DataInbox se construyó desde ese primer caso real y evolucionó funcionalidad a funcionalidad, siempre con la misma regla: primero la necesidad de un cliente, después el desarrollo.
Después han llegado más empresas que usan DataInbox y han vivido un antes y un después. Pero cada una ha necesitado adaptaciones propias, según su negocio y su sector. Porque antes de poner nada en marcha, analizo cómo procesan ellos los pedidos en su día a día.
DataInbox no fue una idea que tuve un fin de semana. Fue la respuesta a un problema que vi con mis propios ojos, en una empresa real, antes de escribir nada. Ese orden no es casualidad. Es la única forma que conozco de construir algo que alguien de verdad necesite.
Si en tu empresa hay un proceso así —uno que todo el mundo da por hecho, que nadie se ha molestado en mirar de cerca— puede que el problema no sea que no tenga solución.
Puede que simplemente nadie se haya sentado contigo el tiempo suficiente para entenderlo del todo.