Usted está aquí:
Cambios de arquitectura de precios
Los precios son una de las diferencias más significativas desde el punto de vista arquitectónico entre Salesforce CPQ y Revenue Management. Si no se explora a tiempo, es una de las áreas donde la complejidad puede surgir más adelante. Recomendamos que el equipo de migración desarrolle una comprensión clara de los cambios del modelo de precios y su impacto en la configuración y la migración antes de que finalicen las decisiones de diseño.
Precios en CPQ
Los precios en Salesforce CPQ se crean alrededor de un motor de reglas. Las reglas de precios evalúan las condiciones y aplican ajustes en un orden secuencial definido. El orden de ejecución importa y cambiar el orden cambia el resultado.
Las construcciones de precios de CPQ comunes incluyen estos componentes.
- Las reglas de precios se basan en condiciones y se ejecutan secuencialmente para calcular el precio de lista, el precio neto y los precios especiales.
- Las programaciones de descuentos son tablas de descuentos basadas en volumen y basadas en plazo aplicadas a partidas de presupuestos.
- Los precios de bloque son precios por niveles que se aplican basándose en intervalos de cantidad.
- Los precios contratados son sustituciones de precios específicas de cuentas almacenadas como registros personalizados de CPQ.
- Los complementos de cálculo de presupuestos (QCP) son códigos personalizados que el motor de reglas no puede gestionar de forma nativa. Estos complementos admiten barandillas de margen, cálculos de líneas cruzadas, visibilidad dinámica y cualquier lógica que el motor de reglas no pueda expresar. Aunque los QCP ofrecen flexibilidad, pueden llegar a ser difíciles de mantener a lo largo del tiempo cuando las reglas se acumulan, las dependencias entre reglas quedan ocultas y falta documentación completa.
Precios en Gestión de ingresos
Gestión de ingresos sustituye el motor de reglas secuenciales por un modelo de procedimiento de precios estructurado. Un procedimiento de precios es una secuencia ordenada nombrada de elementos de precios. Cada elemento realiza una acción de precios específica, como aplicar un precio de lista de precios, aplicar un descuento, agregar un recargo o calcular un límite de margen.
- Los procedimientos de precios ofrecen mayor flexibilidad y capacidad que los conjuntos de reglas de precios de CPQ. Definen la cascada de cálculo de precios para un contexto concreto, como ventas directas, canal de socios o comercio electrónico. Definen la cascada de cálculo de precios para un contexto concreto, como ventas directas, canal de socios o comercio electrónico.
- Los elementos de precios son pasos individuales dentro de un procedimiento. Cada elemento tiene un tipo como Ajuste manual, Programación de descuentos, Lista de precios, Precios basados en atributos, etc. Consulte Utilizar elementos Precios en procedimientos de precios.
- Los planes de procedimiento definen qué procedimiento de precios se aplica en base al contexto. Estos planes activan una lógica de precios diferente para cada canal, segmento de cliente o categoría de producto sin duplicar reglas.
- Los precios basados en atributos fijan los precios de un producto de forma diferente basándose en sus atributos de configuración sin requerir SKU separadas o condiciones de regla de precios para cada variante.
- Precios de uso o consumo es un motor de valoración nativo para modelos de uso basados en consumo y por niveles. No se requiere código personalizado.
- Los precios de artículos contratados proporcionan sustituciones de precios específicas de cuentas o contratos utilizando objetos de Gestión de ingresos estándar, sustituyendo registros personalizados ContractedPrices de CPQ.
Los precios en Gestión de ingresos son flexibles y más fáciles de mantener que la cascada de precios de CPQ. Este es un ejemplo de cascada de precios para una partida de presupuesto en Gestión de ingresos.
El precio unitario neto de 10.260 se calcula aplicando estos descuentos secuencialmente al precio de lista de 15.000.
| Paso | Descripción | Cálculo | Resultado |
|---|---|---|---|
| 1 | Precio de lista | Ninguno | 15.000 |
| 2 | Descuento basado en atributos | 15,000 − 3,000 |
12.000 |
| 3 | Ajuste basado en paquete del 5% | 12,000 − (12,000 × 5%) = 12,00 − 600 |
11,400 |
| 4 | Descuento por volumen del 10% | 11,400 − (11,400 × 10%) = 11,400 − 1,140 |
10,260 |
Rediseño y migración del proceso de precios
La lógica de precios de CPQ rara vez migra sin cambios. Los dos sistemas definen los precios de diferentes formas. Una traducción directa de regla a regla a menudo produce resultados incorrectos porque las reglas de CPQ dependen de la orden de ejecución, que no tiene equivalente directo en los procedimientos de precios de Gestión de ingresos.
El paso del motor de reglas secuenciales de CPQ al modelo de procedimiento de precios de Gestión de ingresos es, por lo tanto, una oportunidad para simplificar el proceso de precios de su empresa. La pregunta clave no es cómo replicar reglas de CPQ existentes, sino qué resultados de precios necesita el negocio en realidad y la forma más clara de expresarlos.
- Realice una auditoría de todas las reglas de precios activas y la lógica de QCP antes de que comience cualquier trabajo de migración. Utilice herramientas con tecnología de IA, como Forsys o IdeaHelix, para generar informes de explicabilidad sobre todas las reglas de precios de CPQ y la lógica de QCP. Comprenda la intención y el propósito comercial de cada regla, ya sea precio de lista, descuento, protección de márgenes o ajuste de canal, antes de intentar cualquier rediseño.
- Clasifique cada regla de CPQ en su equivalente de Gestión de ingresos. Los ajustes de precios sencillos se convierten en elementos de precios, y la lógica cruzada compleja se convierte en Flujos personalizados o Apex dentro del procedimiento.
- Racionalice las reglas de precios que se acumularon con el tiempo sin una propiedad clara. La migración es el momento adecuado para retirar la lógica que ya no es relevante comercialmente.
- Asigne requisitos de precios específicos de canal para canales directos, de socio y de autoservicio a planes de procedimiento en Gestión de ingresos. Esta asignación permite un catálogo de productos único con precios apropiados para el contexto en vez de construcciones de precios separadas para cada canal.
- Si su negocio está avanzando hacia la monetización híbrida, configure los precios basados en consumo y uso en Gestión de ingresos. Los procedimientos de valoración determinan el índice neto final para el consumo utilizando reglas y niveles específicos definidos en tarjetas de índice de atributos, nivel o base.
- Valide los precios rediseñados frente a un paquete de presupuestos depurado, que es un conjunto representativo de presupuestos históricos cuyos precios de salida son conocidos. Si el procedimiento Gestión de ingresos produce los mismos resultados, el rediseño es correcto.
- Para organizaciones de varias divisas, migre y valide una divisa a la vez para evitar el redondeo de desviación entre valores de entrada de lista de precios.
Antes de comprometerse con una estrategia de migración, invierta tiempo en una auditoría de lógica de precios. El volumen y la complejidad de su personalización de precios es uno de los predictores más sólidos del esfuerzo de migración general.
Motor de precios único en todos los canales
La arquitectura de API de Revenue Management aborda el reto de integración de la proliferación de lógica de precios entre canales. Muchas empresas terminan manteniendo reglas de precios separadas para ventas directas, portales de socios y canales de autoservicio, creando tres versiones de la misma verdad que divergen con el tiempo y causan incoherencia para los clientes.
Cada operación de ingresos en Gestión de ingresos se expone como una API. Por lo tanto, el mismo producto, precios y lógica de configuración que potencia la interfaz de usuario de Salesforce puede consumirse por un portal de socios, una experiencia de comercio electrónico de autoservicio o un flujo de compra en producto sin duplicar las reglas. Puede tener un único catálogo y un único motor de precios que funcione para cada canal.
Puede integrar herramientas de visualización externas, como ThreeKit y RenderDraw, para la configuración visual de productos.
