Tener el producto listo no era tener el local listo

El 24 de septiembre llevamos Restoman a Bibi’s, nuestro primer cliente.

Después de años de desarrollar, probar y presentar el proyecto, íbamos a verlo funcionar en un negocio real. Pero esa primera noche no pudimos usarlo como esperábamos.

Un flujo concreto

No íbamos a implementar todo lo que podía hacer Restoman de una vez. Bibi’s lo iba a usar para takeaway: el cliente hace el pedido desde el menú web, paga con Mercado Pago y retira cuando la cocina lo tiene listo.

Podés ver el menú de Bibi’s.

Era un recorrido concreto: pedido, pago, cocina y retiro. El lanzamiento tenía que demostrar que ese recorrido funcionaba en el local, no solamente en nuestras pruebas.

Lo que apareció esa noche

Estuvimos en Bibi’s durante toda la implementación. Mientras los empleados preparaban la cocina para recibir gente, nosotros estábamos terminando los detalles de la configuración del local.

Los bugs aparecieron cuando el gerente de Bibi’s intentó registrarse. En ese momento se cayó la API por primera vez, antes de que hubiera pedidos de clientes. No teníamos una causa confirmada. Los bugs que aparecieron durante la implementación los fuimos resolviendo ahí mismo, en el local.

Pero el bloqueo de esa primera noche no fue solamente técnico.

Bibi’s iba a aceptar únicamente Mercado Pago. La cuenta del local todavía no estaba conectada, y se conectó más tarde esa noche. Sin ese paso, no se podía completar el flujo que habíamos ido a poner en marcha.

Tener la integración en el producto no era lo mismo que tener el medio de pago listo para ese restaurante.

El lanzamiento también era parte del producto

Hasta ese momento, muchas decisiones las habíamos tomado imaginando cómo iba a trabajar un restaurante. En Bibi’s empezamos a encontrarnos con las condiciones concretas de uno.

No alcanzaba con que existieran el menú, el checkout y la pantalla de cocina. Había que llegar con las cuentas creadas, los permisos correctos, el medio de pago conectado y el recorrido completo probado en los dispositivos que iban a usar.

Para el próximo local, eso tiene que ocurrir antes del día del lanzamiento:

• Conectar y probar el medio de pago.
• Preparar las cuentas de quienes van a operar el sistema.
• Probar la pantalla de cocina en el dispositivo real.
• Completar un pedido de punta a punta, incluido el retiro.
• Definir quién responde si algo falla.

No es una lista de funcionalidades nuevas. Es lo necesario para que las que ya construimos se puedan usar.

Lo que me llevé de esa noche es que no alcanza con comprobar que algo funciona una vez. Hay que llegar con todo bien probado, pensar qué puede fallar en cada paso y tener previsto cómo seguir si pasa.

Incluso así, algo se puede romper. Estar preparados también significa tener las herramientas, los accesos y el conocimiento para resolverlo en el momento, no empezar a averiguar qué hacer cuando el local ya necesita operar.

Bibi’s fue nuestro primer cliente, pero también el primer lugar donde tuvimos que aprender esa diferencia: el producto no termina cuando funciona en nuestra computadora. Tiene que poder empezar a funcionar en la del restaurante.