Cuando una cotización viaja por correo, una corrección queda en otro archivo y el pedido se confirma por mensaje, el equipo puede perder de vista qué aceptó el cliente. Un sistema compartido ayuda si deja claras las versiones, los responsables y las condiciones; no basta con convertir cada archivo en un formulario.

Define qué contiene una cotización

Lista cliente, productos o servicios, cantidades, condiciones y vigencia según el negocio. Separa los datos que pueden cambiar de los que deben quedar como fotografía de la propuesta enviada. Si el precio del catálogo cambia después, el equipo necesita saber qué versión recibió el cliente y qué acordó.

Decide quién puede crear, revisar, aprobar y enviar una propuesta, y qué cambios exigen una nueva versión. No todas las empresas requieren el mismo flujo de autorización.

Diseña estados que representen decisiones

Un recorrido posible es borrador, en revisión, enviada, aceptada, rechazada o vencida. Define qué permite pasar de un estado a otro y quién puede hacerlo. «Enviada» debería significar algo verificable para tu equipo, no simplemente que alguien abrió una pantalla.

Si una cotización se modifica luego de enviarse, conserva su historial y aclara cuál está vigente. Una versión rechazada o vencida puede seguir siendo útil para explicar una decisión comercial.

Cuándo nace un pedido

Acuerda qué evidencia activa el pedido: una confirmación del cliente, una aprobación interna u otra condición propia de la operación. Copia al pedido solo la versión aceptada y conserva una referencia a la propuesta. Luego define estados de preparación, entrega y cancelación que correspondan al trabajo real.

Ejemplo hipotético: un comprador acepta diez unidades de un producto. Antes de confirmar, el equipo debe comprobar precio, disponibilidad y fecha acordada. Si falta stock, el sistema puede dejar el pedido pendiente de revisión en lugar de prometer una entrega automática.

Permisos e integraciones

Ventas, administración y despacho no siempre necesitan modificar las mismas condiciones. Aplica permisos por acción y limita la visibilidad de datos comerciales según responsabilidades. OWASP recomienda comprobar la autorización en cada solicitud; ocultar un botón no reemplaza ese control.

Si conectas inventario, pagos o facturación, define cuál sistema administra cada dato, qué pasa cuando una llamada falla y cómo evitar duplicados. No presentes una integración como garantizada antes de revisar la capacidad y condiciones del proveedor.

Deja visibles los supuestos comerciales

Antes de enviar una propuesta, verifica qué datos necesita quien la recibirá: cantidades, moneda, condiciones de entrega, vigencia y exclusiones aplicables. Define de dónde salen y quién aprueba una modificación. El sistema debe conservar la versión comunicada, incluso si cambia después el catálogo; así el equipo evita comparar un pedido aceptado con una condición que aún no existía cuando se cotizó.

Qué probar antes de usarlo

  • Editar una propuesta antes y después de enviarla.
  • Aceptar una versión y comprobar qué información llega al pedido.
  • Rechazar una acción de una persona sin permiso.
  • Recuperarse de una conexión interrumpida sin crear dos pedidos.
  • Consultar quién aprobó un cambio y cuándo ocurrió.

Comienza con el recorrido comercial que más necesita claridad y documenta sus reglas y excepciones antes de comparar propuestas.

Fuentes consultadas

Ordenemos tu recorrido comercial

Cuéntanos cómo pasa una propuesta a pedido y en qué punto se pierde información.

Hablar de cotizaciones y pedidos