El problema no era vender piezas por internet
Una tienda online convencional parte de productos estables, precios conocidos y una compra directa. En Comanai, muchas piezas nacen de una muestra, un plano o una referencia obsoleta. Antes de vender hay que identificar, aclarar, ofertar, aprobar y documentar.
La información útil estaba repartida entre conversaciones, hojas de cálculo, ofertas, pedidos de compra, planos y conocimiento de distintas personas. El riesgo no era solo perder tiempo: también perder el vínculo entre una pieza, su revisión, el cliente y la siguiente recompra.
Las dudas que definieron el producto
- ¿Debía ser un catálogo público, un portal privado o ambos?
- ¿Cómo permitir una solicitud cuando el cliente no conoce la referencia exacta?
- ¿Una oferta se acepta completa o línea por línea?
- ¿Cómo representar conjuntos montados sin tratarlos como piezas independientes?
- ¿Qué documentación ve el cliente y qué información queda para el equipo interno?
- ¿Cómo reutilizar un trabajo anterior sin crear duplicados ni perder trazabilidad?
Cómo lo afrontamos
- 1
Mapear el recorrido real. Seguimos el flujo desde la necesidad técnica hasta la entrega y la recompra. Esto reveló que catálogo, oferta y pedido no podían diseñarse como módulos aislados.
- 2
Separar los roles. Cliente y gestor necesitan la misma historia, pero no las mismas acciones. Diseñamos dos áreas conectadas, con permisos, estados y prioridades diferentes.
- 3
Construir un flujo completo primero. La primera meta no fue acumular funciones, sino completar una operación de principio a fin: solicitud, oferta, aceptación con pedido, seguimiento y cierre.
- 4
Probar con excepciones. Usamos casos incómodos: varias líneas, cantidades distintas, subconjuntos, archivos faltantes, oferta parcial y cambios posteriores. Ahí aparecieron las decisiones importantes.
- 5
Convertir el histórico en activo. El trabajo terminado alimenta una biblioteca técnica para que la siguiente solicitud parta de información ya validada.
Qué cambió durante el desarrollo
De catálogo a sistema operativo comercial
La idea inicial podía parecer un escaparate de piezas. El proceso demostró que el valor estaba en conectar solicitudes, ofertas, pedidos, documentos y seguimiento.
De estados genéricos a hitos comprensibles
Un único estado de pedido no explicaba suficiente. Se incorporaron hitos de revisión, producción, calidad, envío y entrega.
De pieza suelta a estructura de producto
Los conjuntos y subconjuntos exigieron jerarquía, cantidades y documentación propias, sin romper la oferta por líneas.
De aceptar con un clic a aceptar con evidencia
En un entorno B2B, la aceptación debía quedar vinculada al pedido de compra del cliente y a la versión exacta de la oferta.
De archivo final a memoria reutilizable
La documentación dejó de ser un adjunto perdido y pasó a relacionarse con clientes, plantas, equipos, piezas y operaciones anteriores.
Qué resuelve ahora que está en funcionamiento
- Centraliza el contexto técnico y comercial de cada solicitud.
- Permite pedir piezas catalogadas o describir necesidades no catalogadas.
- Mantiene ofertas, revisiones, aceptación y pedido de compra en el mismo expediente.
- Da visibilidad del avance sin depender de cadenas de correo.
- Organiza empresas, plantas, equipos y permisos.
- Conserva documentación e historial para acelerar recompras.
Lo que aprendimos
- Digitalizar no consiste en copiar el proceso actual pantalla por pantalla.
- Las excepciones revelan más sobre el producto que el caso perfecto.
- La trazabilidad debe diseñarse desde el principio; añadirla después resulta costoso.
- Un portal B2B aporta valor cuando reduce preguntas y reconstrucciones, no solo cuando se ve moderno.