Medición del consumo y fijación de precios: ingeniería frente a finanzas

Introducción

Los precios basados en el uso y los híbridos rara vez son estáticos. Cuando la lógica de fijación de precios está codificada de forma rígida, cada pequeño ajuste en un nivel o en una asignación de créditos se convierte en una incidencia técnica. Esto ralentiza el proceso para el departamento financiero y resulta frustrante para los desarrolladores. Entonces, ¿quién debería encargarse de la medición del uso y de los precios basados en ella? Aclaremos esto.

Por qué los cambios en los precios son ahora frecuentes

La fijación de precios ya no es una decisión que se establezca una vez y se olvide. El informe «SaaS & AI Pricing Report», elaborado por la consultora hy y OMR Reviews, que cita datos de Growth Unhinged, afirma que tres de cada cuatro empresas de software estadounidenses modificaron sus precios durante el último año. Eso supone un gran movimiento.

Los modelos también están cambiando. En la encuesta de hy a 180 empresas de software, el 37 % ya utiliza modelos basados en el uso, y el 59 % combina más de una métrica de fijación de precios, como la facturación por usuario junto con el volumen de API. Añadir créditos, realizar experimentos, ajustar los paquetes… y el cambio se convierte en la norma más que en la excepción.

Cómo la lógica de fijación de precios acaba en manos del departamento de ingeniería

Suele ocurrir por casualidad. Al principio, un desarrollador programa una métrica de forma rígida: contar las llamadas a la API, aplicar una tarifa y enviar el total a la factura. Funciona, así que nadie lo cuestiona.

Luego, la tarificación evoluciona. Un nuevo nivel, una cuota gratuita o una tarifa por exceso diferente hacen que alguien abra un ticket, espere a que haya un hueco en el sprint y espere que el lanzamiento no afecte a la facturación. Los plazos se alargan y cada lanzamiento conlleva cierto riesgo. El departamento financiero acaba esperando en una cola que no controla.

Los modelos híbridos agravan esta situación. Cuantos más componentes tenga un precio, en más lugares del código puede ocultarse un cambio.

El coste de una fijación de precios gestionada por ingeniería

Los costes son reales, incluso sin una hoja de cálculo que los demuestre.

• Lanzamientos lentos: una idea de precios puede quedarse estancada durante semanas a la espera del trabajo de producto.
• Errores: la lógica oculta en el código resulta difícil de interpretar para el departamento financiero, por lo que los errores suelen aparecer en las facturas.
• Puntos ciegos del departamento financiero: si el departamento financiero no puede ver cómo se ha calculado una cifra, las disputas tardan más en resolverse.
• Coste de oportunidad: los ingenieros se dedican a mantener el código de facturación en lugar de desarrollar el producto.

Esta es mi opinión: si un cambio de precio requiere una implementación de código, tu fijación de precios avanza al ritmo de tu calendario de lanzamientos, no al ritmo de tu mercado

De qué debería encargarse el departamento de finanzas y de qué debería encargarse el departamento de ingeniería

La responsabilidad no es una cuestión de «o una cosa o la otra». Hay que dividirla según el tipo de decisión.

El departamento de ingeniería se encarga de la instrumentación de eventos, los flujos de datos y la precisión de los datos de uso en la fuente.

Finanzas y el equipo de producto se encargan de las definiciones de métricas, los precios, los paquetes y los créditos.

He aquí una prueba sencilla: si el cambio se refiere a lo que se registra, corresponde a Ingeniería. Si se refiere a cómo el uso registrado se traduce en ingresos, corresponde a Finanzas y al equipo de producto. Por ejemplo, decidir que un plan incluya 1.500 llamadas a la API en lugar de 1.000 es una decisión de precios. Asegurarse de que cada llamada se registre exactamente una vez es una decisión de Ingeniería.

Gobernanza de los cambios en los precios

Ceder el control sin medidas de seguridad invita al caos. Estas son buenas prácticas genéricas, no vinculadas a ninguna herramienta en concreto:

• Aprobaciones: Es necesario contar con la aprobación expresa de los departamentos de finanzas y de producto antes de que un cambio entre en funcionamiento.
• Pruebas: Previsualiza el efecto sobre los datos de uso reales antes de la puesta en marcha.
• Control de versiones: Mantén cada configuración de precios en una versión específica para poder comparar versiones o revertir los cambios.
• Fechas de entrada en vigor: define cuándo se aplica un cambio y cómo se trata el uso ya registrado a mitad de ciclo.
• Registro de auditoría: Registra quién cambió qué y cuándo.

Piensa en ello como una revisión de código para los precios. Nadie lanza código sin que lo revise otra persona, y los precios merecen el mismo cuidado.

Requisitos previos para una fijación de precios dirigida por el departamento financiero

El departamento financiero no puede hacerse cargo de lo que no puede confiar. Hay tres pilares fundamentales que son prioritarios.

Datos de uso limpios. Los eventos duplicados o que faltan socavan cualquier precio que se fije sobre ellos.

Definiciones de métricas consensuadas. Si el departamento de producto define un «usuario activo» de una forma y el departamento financiero de otra, tus facturas resolverán la discusión por ti, y no precisamente de forma amable.

Fuentes fiables. Los datos de uso suelen encontrarse en un almacén de datos, detrás de una API o en archivos. Elige un único sistema de registro para cada métrica y cíñete a él.

Preguntas que hay que plantearse antes de transferir la responsabilidad sobre los precios

Reúne al director financiero, al responsable de producto y al responsable de ingeniería en una misma sala y analicen juntos lo siguiente:

1. ¿Qué cambios en los precios realizamos el año pasado y cuánto tiempo tardó cada uno en implementarse?
2. ¿Existe una definición consensuada para cada métrica facturable?
3. ¿Puede el departamento financiero rastrear cómo una cifra de consumo se convirtió en una línea de factura?
4. ¿Quién aprueba un cambio y cómo lo probamos antes de que entre en vigor?
5. ¿Dónde se almacenan los datos de uso y quién es responsable de su exactitud?

Si no puedes responder a dos o tres de estas preguntas, ese es tu punto de partida.

Cambiar los precios sin reconstruir la medición

Aquí es donde las herramientas pueden ayudar. Según la página de medición de uso de Zenskar, los equipos pueden definir métricas facturables en lenguaje sencillo y dejar que la IA escriba la lógica de agregación, o bien escribir código SQL personalizado para lógicas complejas. El uso se puede extraer de fuentes como Postgres, Athena y MySQL, enviarse a través de una API o cargarse como un archivo CSV. La misma métrica se puede reutilizar en distintos productos, contratos y partidas.

Lo importante para la gestión es que el software de facturación basado en el uso permita que los tramos, los excesos y la periodicidad de facturación cambien independientemente del uso. La lógica de facturación también se puede modificar a mitad de ciclo sin interrumpir el flujo de datos. Una única métrica puede dar lugar a diferentes modelos de precios en distintos contratos, manteniendo estable la medición mientras los precios evolucionan.

Conclusión

El modelo más sólido es el compartido. El departamento de ingeniería se encarga de que los datos de uso sean precisos y fluyan sin interrupciones. Los departamentos de finanzas y de producto gestionan el valor de esos datos dentro de un marco de gobernanza claro. ¿Qué cambio en los precios está pendiente en tu lista de tareas de ingeniería en este momento?

Puntos clave:

• Los precios codificados de forma rígida convierten cada ajuste en los niveles o en los créditos en una incidencia de ingeniería.
• Divide las responsabilidades según el tipo de decisión: el departamento de ingeniería se encarga de la recopilación y la exactitud de los datos de uso, mientras que los departamentos de finanzas y de producto se encargan de las definiciones de las métricas, los precios, los paquetes y los créditos.
• Establece primero las medidas de control: aprobaciones, pruebas, control de versiones, fechas de entrada en vigor y un registro de auditoría.
• Una fijación de precios dirigida por el departamento financiero necesita datos de uso limpios, definiciones de métricas consensuadas y un único sistema de registro por métrica.
• Utiliza las cinco preguntas previas al traspaso para encontrar tu punto de partida.
• Elige herramientas que permitan modificar los precios sin tener que reconstruir el sistema de medición.