Cuando una empresa de servicios B2B decide migrar sus cotizaciones desde Excel a un sistema propio, el problema más común no es técnico. Es de traducción.
El Excel de cotización que lleva años funcionando no es solo una planilla. Es la lógica de negocio de la empresa codificada en fórmulas. Hay reglas sobre márgenes que el equipo conoce de memoria pero que nadie documentó. Hay columnas que se calculan de una forma específica porque un cliente particular negoció condiciones distintas hace tres años. Hay tipos de cambio que se congelan al momento de cotizar porque el precio no puede cambiar aunque el dólar se mueva.
Si el sistema nuevo no entiende esa lógica antes de que alguien empiece a codificar, el resultado es un sistema que técnicamente funciona pero que el equipo abandona en dos meses porque no refleja cómo trabajan en realidad.
Este artículo documenta qué hay que resolver antes de escribir una línea de código.
Tabla de contenidos
El problema que parece simple y no lo es
Una cotización de servicios, vista desde afuera, parece un documento con algunos números y un total. Vista desde adentro de una empresa de servicios B2B real, es un objeto con múltiples capas de complejidad que coexisten al mismo tiempo.
Hay una capa de costos netos: lo que le cuesta a la empresa proveer el servicio, que puede estar en la moneda del proveedor y que no puede quedar expuesta en el documento final que ve el cliente.
Hay una capa de márgenes: el porcentaje que la empresa aplica sobre el costo neto para llegar al precio de venta. Ese margen puede variar por tipo de servicio, por cliente, por volumen o por temporada.
Hay una capa de comisiones: si la empresa trabaja con intermediarios, distribuidores o agencias, hay un porcentaje adicional que se suma o se resta dependiendo de si la comisión la absorbe la empresa o la paga el cliente final.
Hay una capa de paridades y tipos de cambio: cuando los servicios se proveen o se contratan en monedas distintas al peso chileno, cada servicio tiene una paridad de conversión. Y esa paridad, una vez fijada en la cotización, no puede recalcularse con el tipo de cambio del día en que llega el pago.
Hay una capa de estados: una cotización no es un objeto estático. Tiene una historia. Pasa de borrador a enviada, de enviada a revisada, de revisada a aprobada o rechazada, y si se aprueba, pasa a ser un contrato o un file operativo con sus propios estados.
El Excel maneja todo esto, aunque de forma frágil. El sistema nuevo también tiene que manejarlo, pero de forma robusta.
El primer paso: mapear las fórmulas antes de tocar la base de datos
Antes de diseñar ninguna pantalla, el trabajo es sentarse con el equipo que usa el Excel actual y documentar cada columna calculada. No es una reunión de levantamiento de requerimientos genérico. Es una sesión donde se abre el Excel real y se pregunta, columna por columna: ¿qué calcula esto, de dónde viene cada valor y qué pasa si este número es cero?
De un proyecto real de digitalización de cotizaciones para una agencia de turismo mayorista, estas son las columnas que estructuran la lógica de negocio. Las mismas preguntas aplican a cualquier empresa de servicios B2B.
Nett_Service: el costo bruto del proveedor en su moneda local. Puede ser pesos chilenos, dólares, soles peruanos o cualquier otra cosa. Es el punto de partida de toda la cadena de cálculo y nunca puede aparecer en el documento que ve el cliente.
Paridad: el factor de conversión de la moneda del proveedor a dólares. No es el tipo de cambio del día. Es el tipo de cambio acordado o calculado al momento de armar la cotización. Si se cotiza hoy con paridad 950 y el cliente confirma en treinta días con el dólar a 1.020, la cotización no cambia. La paridad es un dato histórico que pertenece a esa cotización específica.
Net_USD: Nett_Service multiplicado por Paridad. Todo se estandariza a dólares para poder comparar servicios de distintos proveedores en distintas monedas.
Margen: expresado como decimal inverso, no como porcentaje directo. Un margen del 20% no se aplica multiplicando por 1.2. Se aplica dividiendo por 0.8. Esa diferencia parece menor hasta que alguien la implementa al revés y todos los precios quedan ligeramente incorrectos.
TTL_Venta: Net_USD dividido por el margen. El precio de venta en dólares antes de cualquier comisión.
Comision_VF: el porcentaje que retiene el intermediario cuando vende. Si hay un canal de venta con condiciones especiales, la comisión se suma sobre el precio de venta para que la empresa reciba lo que corresponde después de que el intermediario descuenta su porcentaje.
TTL_Publico: TTL_Venta dividido por (1 menos Comision_VF). El precio que se le comunica al intermediario para que, después de descontar su comisión, la empresa reciba exactamente TTL_Venta.
TC_CLP: el tipo de cambio a pesos chilenos al momento de cerrar. Igual que la paridad, es un dato histórico de la cotización.
TTL_Publico_CLP: el precio final en pesos para el cliente que paga en Chile.
Esa cadena, que en el Excel son columnas adyacentes en una fila, en la base de datos es un conjunto de reglas de negocio que el sistema debe conocer y respetar sin que el usuario tenga que pensarlas cada vez.
El error más común en la migración: aplanar lo que no debe aplanarse
Cuando alguien que no conoce bien el negocio diseña el sistema de cotización, el error típico es crear una tabla con un campo «precio» y otro campo «margen» y calcular el total. Eso funciona para un caso simple.
Una cotización de servicios B2B rara vez es un caso simple. Tiene múltiples líneas de servicio, cada una con su propio proveedor, su propia moneda, su propio margen y sus propias condiciones. El total de la cotización es la suma de los totales individuales de cada línea, calculados con la lógica específica de cada una.
La estructura de datos correcta tiene dos niveles. Una tabla de cabecera con los datos generales de la cotización: cliente, vendedor, estado, fecha, tipo de cambio general a CLP. Y una tabla de líneas donde cada servicio es un registro independiente con su costo neto, su paridad, su margen, su comisión y sus totales calculados.
La relación entre ambas tablas es lo que permite que el sistema calcule el total general sumando las líneas, que muestre el margen promedio ponderado de toda la cotización y que compare cotizaciones entre sí con datos coherentes.
Si todo queda en una sola tabla, la cotización con doce servicios tiene doce filas que son difíciles de agregar, de comparar y de mantener consistentes cuando cambia algún dato.
Los estados del proceso: qué es un estado y qué no lo es
Los estados de una cotización no son etiquetas. Son permisos.
Cuando una cotización está en estado borrador, el agente puede editar cualquier campo. Cuando está en estado enviada, los campos de precio deberían quedar bloqueados para que nadie los modifique sin volver el documento a borrador. Cuando está en estado aprobada, el sistema debería registrar quién aprobó, cuándo y desde qué canal.
Esa lógica de permisos por estado es lo que le da integridad al proceso. Sin ella, el sistema es solo una base de datos con una columna llamada «estado» que nadie respeta porque no tiene consecuencias prácticas.
Los estados típicos de un proceso de cotización B2B son estos, aunque cada empresa tiene variaciones:
Borrador → el documento está en construcción y puede modificarse libremente.
Enviada → el cliente recibió la cotización. Los precios quedan congelados. Solo se puede editar la vigencia o agregar notas.
En revisión → el cliente pidió cambios. El agente puede modificar el documento, lo que genera una nueva versión numerada.
Aprobada → el cliente confirmó. La cotización se convierte en contrato o file operativo. Los datos pasan al módulo de ejecución del servicio.
Rechazada → el cliente no siguió adelante. El registro se conserva para análisis de pérdida.
Vencida → la cotización tuvo vigencia limitada y no fue respondida en el plazo. Se cierra automáticamente.
Cada transición entre estados debería registrar quién la hizo, cuándo y opcionalmente por qué. Ese historial es lo que permite después analizar en qué etapa se pierden más cotizaciones, cuánto tarda el proceso promedio desde envío a aprobación y qué sectores o tipos de cliente tienen mayor tasa de cierre.
La visibilidad de los márgenes: un problema de arquitectura, no de interfaz
El problema más frecuente en las cotizaciones que maneja una empresa de servicios con intermediarios es la mezcla de información. El margen que la empresa aplica sobre el costo del proveedor es información interna. El precio que recibe el cliente o el intermediario es información externa. Esas dos capas no pueden estar en el mismo documento.
En Excel, la solución habitual es tener columnas ocultas para los costos y los márgenes, y exportar solo las columnas visibles al generar el PDF. Es una solución que funciona hasta que alguien olvida ocultar las columnas antes de imprimir o compartir el archivo.
En un sistema propio, la separación se resuelve en la base de datos. Las columnas de costo neto y margen tienen políticas de acceso que definen qué roles pueden leerlas. El rol del agente interno las ve. El rol del cliente o del portal externo no tiene acceso a esas columnas bajo ninguna circunstancia, independientemente de la interfaz.
El PDF que genera el sistema para el cliente nunca incluye esos datos porque el sistema que genera el PDF consulta la base de datos con las credenciales del rol cliente, que por definición no devuelve esas columnas. No es que el PDF oculte la información. Es que la información no existe para ese contexto.
Lo que el sistema nuevo debe poder hacer que Excel no puede
Digitalizar no debería ser una traducción directa de Excel a pantallas. Debería ser una oportunidad para agregar capacidades que en Excel son imposibles o impracticables.
Control de versiones. Cuando una cotización se modifica después de haber sido enviada, el sistema debería crear una nueva versión y conservar la anterior. El cliente recibe la v2 y el agente puede ver exactamente qué cambió entre la v1 y la v2.
Trazabilidad de comunicaciones. Qué cotizaciones se enviaron a cada cliente, cuándo, desde qué canal, si fueron abiertas. En Excel esa información vive en el correo electrónico de cada agente y desaparece cuando alguien deja la empresa.
Reportes de pipeline. Cuántas cotizaciones están activas en este momento, por qué valor total, en qué estado, con qué probabilidad estimada de cierre. Eso permite proyectar ingresos futuros con datos reales en vez de intuición.
Alertas automáticas. Una cotización enviada que lleva cinco días sin respuesta puede generar una notificación al agente. Una cotización próxima a vencer puede disparar un recordatorio al cliente. Esas automatizaciones en Excel requieren que alguien revise una columna de fechas todos los días.
El orden correcto de trabajo
La decisión sobre tecnología viene después de entender la lógica de negocio, no antes.
El proceso correcto tiene este orden. Primero, documentar el Excel actual columna por columna, incluyendo todas las fórmulas, todas las excepciones por cliente y todas las convenciones informales que el equipo conoce de memoria. Segundo, definir el modelo de datos: qué tablas existen, qué campos tiene cada una, cómo se relacionan entre sí y qué campos son calculados versus almacenados. Tercero, definir los estados del proceso y los permisos que cada estado habilita o bloquea. Cuarto, diseñar las interfaces. Quinto, codificar.
Cualquier proyecto que empiece por el diseño de pantallas o por la elección del framework antes de tener el modelo de datos validado va a necesitar refactorización. La pregunta no es si va a necesitar refactorización, sino cuándo y cuán costosa va a ser.
El Excel es incómodo como sistema operativo, pero es un documento de requerimientos valioso. Tratarlo así desde el inicio es lo que evita construir un sistema que el equipo no reconoce como propio.
Siete y Media es una agencia chilena de desarrollo web y marketing digital B2B. Construimos sistemas de cotización a medida para empresas que tienen lógica de negocio específica que los SaaS del mercado no cubren.
