¿Desarrollo Interno o Software de Comisiones de Venta?

Cuando una empresa por fin decide salir de la hoja de cálculo para liquidar su variable, evaluar soluciones internas para comisiones frente a software especializado, se abre una sola pregunta y de ella depende el año siguiente: ¿lo construimos nosotros o compramos algo que ya existe?

La conversación sobre soluciones internas para comisiones en el comité toma casi siempre el mismo giro. Alguien dice: "nuestro esquema es muy particular, ninguna herramienta del mercado nos va a servir; necesitamos soluciones internas de comisiones". Y suena razonable: se tiene el conocimiento del negocio, hay un área de desarrollo o un proveedor de confianza, y se evita depender de un tercero.

Este artículo compara las soluciones internas de comisiones con el software especializado —tres, en realidad— con evidencia de campo en vez de con argumentos de proveedor. Está construido sobre una conversación con el responsable de liquidación de comisiones de una cadena de retail de moda con operación nacional en Colombia, que gestiona el variable de más de 1.500 personas. Su empresa no venía de Excel: venía de algo aparentemente mejor —una herramienta desarrollada a la medida— y llevaba una década descubriendo por qué eso tampoco era una solución. Después construyeron una segunda versión, con requerimientos levantados y un proveedor dedicado. Proyectada a ocho meses, llevaba dos años cuando se canceló en pruebas.

Su diagnóstico, textual, resume el hallazgo central:

"Sí era bueno el desarrollo, pero de pronto no estaba adaptado a la necesidad de las comisiones."

El código no era el problema. Las soluciones internas para comisiones fracasan porque liquidar comisiones de venta es un dominio con reglas propias (ver solución para finanzas y operaciones), y un equipo de desarrollo —interno o contratado— que nunca ha liquidado una nómina variable no sabe qué preguntar. En Compensix hemos visto este patrón repetirse en México, Colombia, Argentina y Chile con una consistencia que ya no sorprende.

La respuesta corta

Si necesitas decidir hoy entre soluciones internas para comisiones o software especializado, esta es la síntesis del artículo:

• Entre el 80% y el 90% de un esquema que la empresa considera "único" es configuración, no código: rangos por cumplimiento, aceleradores, múltiples cuotas simultáneas, prorrateo por días trabajados, atribución y jerarquía de tiendas o territorios. Todo eso ya está resuelto en cualquier motor especializado serio.
• El desarrollo interno se justifica solo en el 10% restante, y aun así conviene construirlo sobre una base que ya resuelva lo demás, no desde cero.
• La variable que decide no es el presupuesto: es si el equipo que va a construirlo ha liquidado comisiones antes. Si no lo ha hecho, el proyecto no falla por código; falla por las reglas que nadie sabía que había que preguntar. Las ocho que siempre aparecen están en la sección 13.
• Hay casos legítimos donde el desarrollo propio gana. Están en la sección 4, y son menos de los que la mayoría de los comités cree.

Lo que sigue es la evidencia detrás de cada uno de esos cuatro puntos.

1. El punto de partida real no es Excel: es "el mínimo viable más manualidad"

Conviene empezar por corregir el diagnóstico. Muy pocas empresas de tamaño medio liquidan cien por ciento en Excel. Lo que tienen es algo peor de describir y más difícil de reemplazar: un sistema propio que resuelve una parte y deja el resto en manos de una persona.

"Originalmente se creó una herramienta adaptada a las necesidades del negocio en su momento, pero ya lleva casi 10 años. Primero, por lo que entiendo del área técnica, el formato en el que se creó ya no se puede trabajar sobre él. Y segundo, a medida de los cambios que hemos tenido en el negocio en todos estos años, la herramienta ofrece el mínimo viable. Básicamente nos da un input, y el resto casi que todo toca hacerlo manual."

Ese "nos da un input" es la definición de una automatización a medias, y es un estado peligroso por tres razones:

• Oculta el costo. Como algo se automatizó, el proceso "ya está resuelto" en el discurso interno, aunque el 70% del trabajo siga siendo manual.
• Concentra el riesgo. La parte manual vive en la cabeza de quien la ejecuta, no en un sistema.
• No se puede auditar. El resultado final no es trazable hasta la regla que lo produjo, porque en el medio hubo pasos humanos sin registro.

Si tu punto de partida se parece a esto, la comparación que debes hacer no es "Excel vs. software". Es "el costo real de mi proceso actual vs. cada una de las rutas de salida". Para dimensionar el primero, el análisis está en 5 razones por las que Excel no es la solución correcta para el cálculo de comisiones de venta.

2. Las tres rutas comparadas: genérico, a la medida, o configurable

El entrevistado hizo por su cuenta el estudio de mercado que muchos comités piden y pocos ejecutan:

"Yo estoy haciendo la búsqueda de las otras marcas. En la mayoría me he encontrado que tienen software propios o adaptados, o sea, no hay como una herramienta genérica. La única que tenía una herramienta genérica, que era una herramienta europea, ya tuve una reunión con ellos y la verdad no tenía el alcance, y en este momento se encuentran cerrados a desarrollo por los próximos dos años porque tienen otras prioridades."

Su conclusión fue que había que desarrollar a la medida. Es una conclusión comprensible, pero se apoya en una dicotomía falsa: o herramienta genérica rígida, o desarrollo desde cero. Existe una tercera ruta.

La pregunta correcta no es "¿genérico o a la medida?", sino "¿qué parte de mi esquema necesita código nuevo y qué parte solo necesita configuración?". En la enorme mayoría de los casos que hemos evaluado en Compensix, entre el 80% y el 90% de un esquema "único" es configuración sobre primitivas conocidas —rangos, aceleradores, múltiples cuotas, prorrateo, atribución, jerarquía de tiendas—, y solo el resto justifica desarrollo. Diseñar todo desde cero para atender ese 10% es la decisión más cara del proyecto.

Sobre cuánto debería tardar realmente la puesta en marcha, lo tratamos en dónde encuentro un software de cálculo de comisiones con implementación rápida y sencilla.

3. El mito de "nosotros somos únicos"

Es la objeción más común y la más honesta: ninguna empresa cree parecerse a otra. Pero conviene separar dos cosas que se confunden.

Lo que casi siempre es único: los valores. Los porcentajes, los rangos, los nombres de los cargos, la periodicidad, la estructura de tiendas y territorios, los productos.

Lo que casi nunca es único: la mecánica. Rangos por cumplimiento, presupuesto distribuido, múltiples objetivos simultáneos, prorrateo por días trabajados, reglas por cargo, consolidación mensual desde un dato transaccional. Un caso "irrepetible" de retail de moda (como Georgie Boy) comparte más del 80% de su mecánica con una cadena de farmacias, una red de concesionarios o una fuerza de venta de telecomunicaciones.

La consecuencia práctica: si tu esquema es único en los valores pero estándar en la mecánica, no necesitas un desarrollo. Necesitas un motor de reglas.

4. Cuándo sí conviene el desarrollo interno

Este artículo argumenta contra las soluciones internas para comisiones como ruta por defecto, no como opción. Hay cuatro situaciones en las que construir sí es la decisión correcta, y conviene reconocerlas para no descartarlas por inercia.

1. Tu mecánica —no tus valores— es genuinamente irrepetible. Si tu esquema depende de una variable que ningún motor modela porque nadie más la tiene —una fórmula regulada por tu industria, un reparto que depende de un algoritmo propietario, una unidad de medida que no es dinero ni volumen—, entonces estás en el 10% real. Ojo: la prueba no es que a ti te parezca raro; es que un proveedor especializado, viéndolo, te diga que no lo puede configurar.

2. El esquema es en sí mismo una ventaja competitiva. En algunos negocios el modelo de incentivos es parte del producto y no algo administrativo. Si tu forma de remunerar a la fuerza comercial es una razón por la que la gente trabaja contigo y no con la competencia, tiene sentido controlar esa pieza.

3. Tu equipo ya construyó liquidación antes. Esta es la variable que más pesa y la que casi nunca se evalúa. Si el equipo que va a construirlo —interno o contratado— ya entregó y mantuvo un sistema de compensación variable en producción, la brecha de dominio desaparece y el riesgo cae drásticamente. Si nunca lo ha hecho, ninguna cantidad de talento técnico compensa lo que no sabe preguntar.

4. Restricción regulatoria o de datos que impide un tercero. Sectores con exigencias de residencia de datos o de aislamiento que ningún proveedor cumple. Es una razón legítima, aunque cada vez menos frecuente.

Y una condición que aplica a los cuatro casos: incluso cuando el desarrollo se justifica, rara vez se justifica desde cero. Lo razonable es construir la pieza propia sobre una base que ya resuelva versionado, retroactividad, atribución, trazabilidad y cierre de período —las ocho primitivas de la sección 13—, en lugar de reimplementarlas.

Si ninguna de las cuatro situaciones describe tu caso, lo que sigue explica qué te espera si tomas esa ruta de todas formas.

5. Primera trampa: el desarrollo propio caduca antes que el negocio

La frase técnica más reveladora de toda la conversación es que el formato en el que se creó la herramienta ya no permite trabajar sobre él. No es que falten funcionalidades: es que el código llegó a un punto en el que modificarlo dejó de ser viable.

Diez años es mucho tiempo en tecnología, pero las soluciones internas para comisiones no evolucionan con la empresa. Un desarrollo a la medida se congela en el stack, las convenciones y las dependencias del año en que se escribió. Y mientras tanto:

Un producto de software especializado absorbe esas cuatro curvas como parte de su negocio: es lo que se está pagando. Un desarrollo propio las traslada íntegras al balance de la empresa que lo encargó, y esa cuenta no aparece en la cotización inicial.

6. Segunda trampa: se construye sobre la dinámica de hoy

Este es el punto donde el caso se vuelve concreto y demoledor.

"Nosotros somos una industria de venta de ropa. Nuestro foco era una línea, y de un par de años para acá se abrió otra. Pero para una misma tienda se sesgan las dos líneas: un presupuesto por una línea, un presupuesto por la otra. Los asesores en esas tiendas tienen dos objetivos. La herramienta actual no es capaz de que haya dos tipos de presupuestos."

Léelo otra vez, porque es el corazón del asunto. Una decisión comercial perfectamente normal —abrir una segunda línea de producto— dejó obsoleta una herramienta de liquidación. No cambió el país, ni la ley, ni el modelo de negocio: se agregó una línea. Y el sistema no lo soportó, porque en su modelo de datos un vendedor tenía un presupuesto, no varios.

Ese es el modo de falla característico del desarrollo a la medida. Se levantan los requerimientos de la operación de hoy, se modela exactamente eso, y se optimiza. El resultado es un sistema perfecto para un negocio que en tres años ya no existe. El propio entrevistado lo diagnosticó así al hablar de la segunda versión:

"Se hizo muy a la dinámica estándar y no se proyectó que se podían hacer cambios, entonces se quedó obsoleta."

La pregunta que casi nadie hace en el levantamiento de requerimientos no es "¿cómo funciona hoy tu esquema?". Es "¿qué tendría que pasar en tu negocio para que este modelo deje de servir?". Un equipo que ha construido liquidación antes hace esa pregunta por reflejo. Uno que no, la descubre en producción.

7. La complejidad real que un desarrollo tiene que absorber

Cuando alguien dice "nuestro esquema es sencillo, es una tabla por rangos", conviene desconfiar. Este es el esquema del caso, descrito por quien lo liquida:

La tabla, en efecto, es simple. Rangos de cumplimiento por cargo: del 90 al 100% del presupuesto se paga un porcentaje, del 100 al 110% otro, y así sucesivamente.

Todo lo demás no lo es:

1. El presupuesto es diario, no mensual. El área de planeación entrega un presupuesto por tienda y por día, para todas las tiendas del país.
2. El presupuesto se reparte en la tienda, no en la oficina. El jefe de tienda entra al aplicativo, ve el presupuesto del día y lo divide entre los asesores que efectivamente trabajaron.
3. Quién trabajó cambia todos los días. Descansos, incapacidades, renuncias, ingresos. En sus palabras: "las novedades son algo del día a día".
4. Hay dos presupuestos simultáneos por tienda, uno por cada línea de producto, y el mismo asesor responde por ambos.
5. Hay cuatro cargos distintos dentro de una misma tienda, cada uno con su lógica de comisión.
6. Al cierre del mes se consolida el acumulado diario y se cruza contra la venta real extraída del ERP.

Eso no es una tabla por rangos: es una matriz de día × tienda × línea × cargo × persona, con el denominador cambiando a diario. Un desarrollador que recibe el requerimiento "calcular comisión por rangos de cumplimiento" y no entiende de dominio va a construir un motor mensual por persona. Funcionará en la demo y se romperá en la primera prueba con datos reales.

Este es exactamente el fenómeno que describimos en por qué las comisiones de venta se vuelven complejas con el crecimiento del equipo: la complejidad no está en la fórmula, está en la granularidad y en las excepciones.

8. Quién carga el dato: el requisito que decide la arquitectura

Hay un detalle operativo en este caso que vale más que cualquier especificación funcional:

"Yo estoy solo en el área, entonces no tengo el alcance para manejar [más de mil quinientas] personas. Ahí dentro nos encontramos incapacidades, novedades, renuncias, y no tendría cómo darle manejo a toda esa información yo solo."

Una persona administra el variable de más de mil quinientas. Eso no es una anomalía: es la norma en empresas de este tamaño en la región. Y tiene una consecuencia arquitectónica que muchos requerimientos omiten: el sistema no puede tener un solo usuario administrador. Tiene que ser multiusuario con roles y permisos por punto de venta, porque la única forma de que el dato entre a tiempo y correcto es que lo cargue quien lo conoce —el jefe de tienda—, no quien liquida.

Las preguntas de diseño que se desprenden:

• ¿Quién puede ver y modificar el presupuesto de una tienda, y quién no?
• ¿Qué pasa si un jefe de tienda no carga el reparto de un día?
• ¿Cómo se audita quién cambió qué y cuándo?
• ¿Cómo se corrige un día ya cerrado sin recalcular el mes entero a mano?

Un desarrollo pensado como "un módulo de cálculo" no contempla nada de esto, porque asume un operador central. Un sistema de liquidación real es, ante todo, un sistema de captura distribuida de datos con control de acceso; el motor de cálculo es la parte fácil.

9. El costo de la manualidad a escala

"Al tener tanta manualidad, y ser una cantidad tan amplia de personas, termina prestando para el error. Es algo del día a día."

Los reclamos por liquidación no son un problema de actitud del equipo comercial: son la consecuencia estadística inevitable de un proceso manual aplicado a miles de registros. Cuando cada mes se procesan decenas de miles de cruces —persona × día × línea × cargo— con intervención humana en el medio, la pregunta no es si habrá errores, sino cuántos.

Y cada error cuesta en cuatro monedas distintas:

• Tiempo del analista, que deja de liquidar para investigar un caso.
• Tiempo del jefe de tienda, que escala y hace seguimiento.
• Confianza, que es la moneda más cara: un vendedor que ha visto dos errores en su liquidación revisa las siguientes con desconfianza, aunque estén bien.
• Dinero, cuando el error va a favor del empleado y ya se pagó.

Si te preguntas a partir de qué punto esto deja de ser sostenible, lo cuantificamos en a partir de cuántos vendedores deberías dejar de usar Excel para el cálculo de comisiones de venta.

10. "Ya tenemos estandarizada la manualidad": la trampa del dolor normalizado

De todo lo que se dijo en esa hora, esta es la frase que más proyectos ha matado en la región:

"Es una necesidad latente, pero digamos que ya tenemos estandarizada la manualidad, entonces no es de carácter crítico, no tiene que estar listo a corto plazo."

Ahí está el mecanismo completo. Un proceso doloroso, ejecutado durante años por gente competente, se vuelve rutina. La rutina se documenta. La documentación se convierte en "procedimiento". Y en el momento en que el dolor tiene procedimiento, deja de ser una urgencia y pasa a ser un costo fijo invisible.

El problema es que ese costo fijo no desapareció. Sigue ahí, en horas mensuales, en errores, en el riesgo de que la única persona que sabe hacerlo renuncie. Simplemente dejó de tener quien lo defienda en el comité de presupuesto.

Cómo se rompe la trampa, en tres movimientos:

1. Cronometra el ciclo. Horas-persona por mes de cierre, de principio a fin, incluyendo correcciones. Ese número, multiplicado por doce y por el costo de la hora, es el primer renglón del caso de negocio.
2. Cuenta las reclamaciones. Cuántas por mes, cuántas horas consumió cada una, cuántas terminaron en un ajuste retroactivo.
3. Ponle nombre al riesgo de concentración. Si la persona que ejecuta el proceso manual se va mañana, ¿cuánto tarda la empresa en volver a liquidar bien? Esa respuesta suele mover más al comité que cualquier ahorro.

11. Autopsia: dos años, un equipo dedicado, cancelado en pruebas

La empresa del caso no fue negligente. Hizo, sobre el papel, todo lo que un manual recomienda:

• Contrató al proveedor que conocía el sistema original.
• Levantó los requerimientos completos. En palabras del entrevistado: "los requerimientos ya están levantados, realmente ya sabemos qué queremos y qué necesitamos que nos diseñen".
• Le dedicó un año de trabajo conjunto.
• Hizo pruebas antes de salir a producción.

Y aun así:

"Cuando empezamos a hacer las pruebas, como que no se cumplió con los objetivos y decidieron dar por terminado el proyecto. Las comisiones, los cálculos, todo como que no nos daba de acuerdo a las expectativas. Era algo que teníamos proyectado en ocho meses, ya llevaba dos años, entonces decidieron acabar el proyecto porque sintieron que el proveedor no estaba dando el respaldo que requeríamos."

Ocho meses proyectados, veinticuatro reales, cero en producción. Es el patrón típico de las soluciones internas para comisiones. Vale la pena descomponer las causas, porque ninguna es exótica:

Fíjate en la tercera fila, porque es la más corregible: el fallo no fue construir mal, fue descubrirlo tarde. Un proyecto de liquidación debería validar contra un mes real ya liquidado desde la primera iteración, no al final. Si el mes 1 no cuadra línea por línea con lo que se pagó realmente, no se sigue construyendo: se corrige el modelo.

12. La brecha de dominio, explicada

Aquí está el núcleo del artículo. La frase del entrevistado —"sí era bueno el desarrollo, pero no estaba adaptado a la necesidad de las comisiones"— describe algo específico que conviene nombrar bien.

Un equipo de desarrollo competente sabe construir: modela datos, escribe pruebas, diseña interfaces, despliega. Lo que no tiene, si nunca ha trabajado en compensación variable, es el catálogo de casos que siempre aparecen. Y ese catálogo no está en el requerimiento, porque quien escribe el requerimiento tampoco sabe que hay que pedirlo: son cosas que el negocio da por obvias y que el sistema tiene que resolver explícitamente.

Una definición útil y citable: la liquidación de comisiones de venta no es un problema de cálculo, es un problema de estado. Lo difícil no es multiplicar una venta por un porcentaje; es saber, en cualquier momento del pasado, qué plan estaba vigente, quién estaba asignado a él, qué ventas contaban, qué se pagó, y qué cambió después.

13. Las 8 cosas que un desarrollador que nunca ha liquidado comisiones no sabe

Este es el checklist que recomendamos poner sobre la mesa antes de escribir la primera línea de código, tanto si el equipo es interno como si es un proveedor externo. Si el proveedor no pregunta por estos ocho puntos sin que se los menciones, no conoce el dominio.

1. Versionado del plan. Los planes cambian a mitad de año. El sistema debe conservar todas las versiones y saber cuál estaba vigente en cada fecha. Recalcular un mes de hace ocho meses debe dar el mismo resultado que dio entonces.
2. Retroactividad y recálculo. Una venta se registra tarde, un presupuesto se corrige, un cargo se reclasifica. El sistema debe recalcular períodos cerrados y generar un ajuste diferencial, no reemplazar el histórico.
3. Reversión de comisiones ya pagadas. Devoluciones, anulaciones, cartera que no se recaudó. Hay que decidir —y programar— si se descuenta del período siguiente, si se retiene un porcentaje, y con qué tope.
4. Atribución. Cuando más de una persona interviene en una venta, o cuando un asesor cubre otra tienda, ¿a quién se le acredita y en qué proporción? Es la fuente número uno de reclamaciones.
5. Novedades de personal a mitad de período. Ingresos, retiros, incapacidades, traslados de tienda, cambios de cargo. El presupuesto y la comisión deben prorratearse, y la regla de prorrateo hay que definirla antes, no en la primera excepción.
6. Proraterio del presupuesto por disponibilidad. En el caso que analizamos, el presupuesto diario se reparte solo entre quienes trabajaron ese día. Eso significa que el denominador de cada persona cambia diariamente y el acumulado mensual no es una simple suma de metas fijas.
7. Trazabilidad de extremo a extremo. Ante un reclamo, hay que poder mostrar el camino completo: esta venta, con esta regla, de esta versión del plan, produjo este valor, aprobado por esta persona, en esta fecha. Sin eso, la discusión se resuelve por jerarquía y no por evidencia.
8. Cierre y bloqueo del período. Un período liquidado y pagado debe quedar sellado. Si algo se toca después, tiene que ser un ajuste registrado, no una edición silenciosa.

Ninguno de estos ocho puntos suele aparecer en un requerimiento escrito por el área usuaria, porque son obvios para quien lo vive y desconocidos para quien lo programa. Ese vacío es, literalmente, la distancia entre un proyecto de ocho meses y uno de dos años.

14. La integración con el ERP no es negociable

En el caso, la venta real vive en un ERP corporativo de amplio uso en el retail colombiano, y la posición del entrevistado fue inequívoca:

"Ese ERP lleva muchos años con nosotros y no se va a tocar. Yo creería que por tema de estandarización y para evitar margen de error, lo más práctico sería que se integrara, que extrajera la información integrada."

Tiene toda la razón, y por un motivo que va más allá de la comodidad: cada exportación manual es un punto de fallo y un punto de discusión. Si el archivo de ventas se descarga, se filtra y se sube a mano, entonces ante un reclamo nunca se sabe si el problema fue la regla o el archivo.

Los flujos mínimos que una implementación seria debe cubrir:

Los criterios técnicos para evaluar esta parte están en dónde puedo adquirir un sistema de cálculo de comisiones que se integre con mi CRM.

15. El costo total que nadie pone en la cotización

Cuando el comité compara "desarrollo propio" contra "suscripción a una plataforma", casi siempre compara el precio de la primera contra el precio de la segunda. Es una comparación incompleta. Estos son los renglones que faltan del lado del desarrollo:

• El costo de oportunidad del equipo interno. Si tu área de desarrollo dedica seis meses a esto, son seis meses que no dedica al negocio.
• El mantenimiento evolutivo. Cada cambio de esquema —cada 12 a 24 meses— es un ticket, una priorización y un despliegue.
• La dependencia de personas. El desarrollador que entendía la lógica se va, y el sistema entra en modo "no tocar".
• El costo del proyecto que no llega a producción. En el caso analizado: dos años de trabajo conjunto con valor de negocio cero. Ese es el escenario que la cotización nunca contempla y el que más veces ocurre.
• La reescritura a los 8-10 años, que es la historia con la que empezó este artículo.

La comparación honesta es a cinco años, incluyendo mantenimiento y una probabilidad realista de fracaso del proyecto. Hecha así, la aritmética cambia de signo en casi todos los casos. El patrón está documentado en por qué las herramientas internas para el cálculo de comisiones de ventas fallan.

16. El requerimiento que sí sirve: 12 preguntas antes de licitar

El entrevistado describió con precisión lo que viene después de su recomendación interna: elevar la necesidad, un área de mejoramiento continuo, especialistas de proyectos, una licitación con al menos tres proveedores. En ese proceso, la calidad del requerimiento determina el resultado más que la calidad de los proveedores.

Estas son las doce preguntas que debe responder el documento antes de salir a cotizar:

1. ¿Cuál es la unidad mínima de la meta: mes, semana, día? ¿Y la unidad mínima de la venta?
2. ¿Cuántos objetivos simultáneos puede tener una misma persona?
3. ¿Quién define el presupuesto y quién lo distribuye entre las personas?
4. ¿Cuántos roles distintos van a usar el sistema y qué puede hacer cada uno?
5. ¿Cómo se manejan las novedades de personal a mitad de período?
6. ¿Cuántos tipos de cargo comisionan y en qué se diferencian sus reglas?
7. ¿Qué pasa cuando una venta se anula o no se recauda?
8. ¿Cuánto tiempo hacia atrás se debe poder recalcular, y con qué versión del plan?
9. ¿Qué sistemas deben integrarse y en qué dirección viaja cada dato?
10. ¿Qué debe poder ver el vendedor y qué no?
11. ¿Cómo se prueba? ¿Contra qué mes real y con qué criterio de aceptación línea por línea?
12. ¿Quién configura un cambio de esquema después de la puesta en marcha: el proveedor, TI, o el área usuaria?

La número 11 y la número 12 son las que más proyectos salvan. La 11 obliga a validar temprano —el error del caso analizado fue descubrirlo en pruebas finales, a los dos años—. La 12 define si vas a tener un sistema o una dependencia: si cada cambio de la tabla comisional necesita un desarrollo, en dos años vuelves a estar donde empezaste.

17. Cómo evaluar a los proveedores

El entrevistado mencionó un criterio que en Latinoamérica pesa más de lo que suele reconocerse en los papeles de licitación:

"Normalmente siempre buscan a alguien que pueda darle soporte técnico, al menos presencial alguna vez que se presente."

Es legítimo, y conviene traducirlo a criterios evaluables en lugar de dejarlo como una sensación:

• Presencia local real, con nombre y responsable, no solo una dirección.
• Zona horaria compatible para el cierre mensual, que es cuando se necesita soporte.
• Quién responde cuando cambia el esquema, y en cuánto tiempo.
• Referencias verificables con volumen y complejidad comparables a la tuya.
• Prueba de concepto obligatoria sobre un mes real ya liquidado, antes de firmar. Es el filtro más barato que existe y el que más proveedores elimina.

Sobre este último punto insistimos siempre: si un proveedor no está dispuesto a modelar tu mes más difícil antes de que firmes, la conversación no debería continuar. Lo que aparece en ese ejercicio no son errores de la herramienta; son las reglas que tu organización nunca documentó y que estaban a punto de convertirse en el sobrecosto de tu proyecto.

Conclusión: cómo responder la pregunta en tu caso

Volvamos a la pregunta del título. La respuesta sobre soluciones internas para comisiones no es "software siempre" ni "desarrollo nunca": es una secuencia de tres decisiones, en este orden.

Primero, separa mecánica de valores. Si lo que te hace único son los porcentajes, los rangos, los cargos y la estructura de tiendas, eres configuración. Si lo que te hace único es una regla que ningún motor modela, entonces sí estás en el 10% que justifica código.

Segundo, evalúa al equipo antes que al presupuesto. ¿Quien va a construirlo ya entregó y mantuvo un sistema de compensación variable en producción? Si la respuesta es no, el riesgo no está en el precio: está en las ocho reglas que nadie sabrá que había que preguntar.

Tercero, exige la prueba antes de firmar. Un mes real ya liquidado, modelado y comparado línea por línea. Es el filtro más barato que existe, y aplica igual al proveedor de software que al equipo de desarrollo interno.

La empresa del caso no fracasó por falta de recursos, ni de requerimientos, ni de compromiso. Fracasó porque el equipo que construyó el sistema no conocía el dominio, y porque el diseño se hizo sobre la operación de un año concreto en lugar de sobre las reglas que la gobiernan. Para la mayoría de las empresas la ruta que funciona es la intermedia: un motor que ya resuelve las primitivas del dominio, configurado —no programado— para tu esquema, y desarrollo solo en la pieza que de verdad es tuya.

En Compensix construimos exactamente eso: una plataforma que empieza por la estrategia del plan, modela su impacto y su retorno, lo comunica al equipo y solo al final lo calcula, con integraciones hacia el ERP, el CRM y la nómina. No porque el desarrollo a la medida sea siempre malo, sino porque casi nunca es el 100% del proyecto que la gente cree que es.

¿Estás por salir a licitar? Agenda una demostración de 30 minutos y modelamos tu mes más complejo —el de las excepciones— sobre datos reales, antes de que escribas una línea del requerimiento.

FAQ:

P: ¿Desarrollo interno o software de comisiones de venta: qué conviene más? R: Depende de qué parte de tu esquema necesita realmente código nuevo. Entre el 80% y el 90% de un esquema que la empresa considera "único" es configuración sobre primitivas conocidas. Para ese 10-20% que sí requiere código especial, existe el desarrollo a medida: rangos por cumplimiento, aceleradores, múltiples cuotas simultáneas, prorrateo por días trabajados, atribución y jerarquía de tiendas o territorios. Todo eso ya está resuelto en un motor especializado. El desarrollo interno se justifica en el 10% restante, y aun así conviene construirlo sobre una base existente en lugar de desde cero.

P: ¿Cuándo sí tiene sentido desarrollar internamente un sistema de comisiones? R: En cuatro situaciones. Primera, cuando tu mecánica —no tus valores— es genuinamente irrepetible y un proveedor especializado, viéndola, te dice que no la puede configurar. Segunda, cuando el esquema de incentivos es en sí mismo una ventaja competitiva y parte del producto. Tercera, y la más determinante, cuando el equipo que va a construirlo ya entregó y mantuvo un sistema de compensación variable en producción. Cuarta, cuando existe una restricción regulatoria o de residencia de datos que ningún proveedor cumple.

P: ¿Por qué fracasan los desarrollos internos de sistemas de comisiones de venta? R: Por cuatro causas recurrentes. La brecha de dominio: el equipo sabe programar pero no sabe qué casos siempre aparecen en una liquidación, y no puede preguntar por lo que no conoce. El requerimiento estático: se levanta sobre la operación de hoy y no proyecta cambios de negocio ordinarios, como abrir una segunda línea de producto. La validación tardía: el error aparece en pruebas finales, cuando corregir el modelo ya es reescribirlo. Y el desgaste del patrocinio, cuando pasan dos años sin entregar valor.

P: ¿Qué debe saber un desarrollador antes de construir un sistema de liquidación de comisiones? R: Como mínimo ocho cosas que rara vez aparecen en un requerimiento escrito por el área usuaria: versionado del plan, retroactividad y ajustes diferenciales, reversión de comisiones ya pagadas, reglas de atribución, prorrateo por novedades de personal, prorrateo del presupuesto según disponibilidad diaria, trazabilidad de extremo a extremo, y cierre y bloqueo del período. Si un proveedor no pregunta por estos puntos sin que se los menciones, no conoce el dominio.

P: ¿Cuánto debería tardar implementar un software de comisiones de venta? R: Un desarrollo a la medida completo típicamente toma entre 12 y 24 meses hasta producción, con un riesgo real de no llegar. Un software genérico rígido se instala en semanas, pero solo sirve si tu esquema se parece al estándar. Una plataforma configurable de dominio suele estar en producción entre 4 y 12 semanas, porque el motor ya existe y lo que se hace es configurarlo. En los tres casos, la validación debe hacerse contra un mes real ya liquidado desde la primera iteración, no al final.

P: ¿Qué debo pedirle a un proveedor antes de firmar? R: Una prueba de concepto sobre tu mes más difícil, con datos reales ya liquidados, comparando línea por línea contra lo que efectivamente se pagó. Es el filtro más barato que existe y el que más proveedores elimina. Además: presencia y soporte local con nombre y responsable, zona horaria compatible con tu cierre mensual, referencias verificables de volumen comparable, y una respuesta clara a quién configura un cambio de esquema después de la puesta en marcha.