Ti trovi qui:
Modifiche all'architettura dei prezzi
I prezzi sono una delle differenze architetturalmente più significative tra Salesforce CPQ e Gestione del reddito. Se non viene esplorata in anticipo, è una delle aree in cui la complessità può emergere in seguito. Si consiglia al team di migrazione di sviluppare una chiara comprensione delle modifiche del modello di prezzi e del relativo impatto sulla configurazione e la migrazione prima che le decisioni di progettazione siano definitive.
Prezzi in CPQ
I prezzi in Salesforce CPQ sono basati su un motore di regole. Le regole sui prezzi valutano le condizioni e applicano le rettifiche in un ordine sequenziale definito. L'ordine di esecuzione è importante e la modifica dell'ordine modifica il risultato.
I costrutti di prezzo CPQ comuni includono i seguenti componenti.
- Le regole sui prezzi sono basate su condizioni ed eseguite in sequenza per calcolare il prezzo di listino, il prezzo netto e i prezzi speciali.
- Le pianificazioni sconti sono tabelle di sconti basate sui volumi e sui termini applicate alle voci preventivo.
- I prezzi di blocco sono prezzi a livelli che si applicano in base agli intervalli di quantità.
- I prezzi contrattuali sono sostituzioni di prezzi specifiche dell'account memorizzate come record personalizzati CPQ.
- I plug-in per il calcolo dei preventivi (QCP) sono codici personalizzati che il motore di regole non è in grado di gestire in modo nativo. Questi plug-in supportano guardrail di margine, calcoli trasversali, visibilità dinamica e qualsiasi logica che il motore di regole non è in grado di esprimere. Benché i QCP offrano flessibilità, possono diventare difficili da mantenere nel tempo quando le regole si accumulano, le dipendenze tra le regole diventano nascoste e manca una documentazione completa.
Prezzi in Gestione del reddito
Gestione del reddito sostituisce il motore di regole sequenziali con un modello di procedura di calcolo dei prezzi strutturato. Una procedura di calcolo dei prezzi è una sequenza denominata e ordinata di elementi prezzi. Ogni elemento esegue un'azione specifica sui prezzi, ad esempio applicare un prezzo di listino prezzi, applicare uno sconto, aggiungere un supplemento o calcolare un minimo di margine.
- Le procedure di calcolo dei prezzi offrono maggiore flessibilità e funzionalità rispetto ai set di regole di prezzo CPQ. Definiscono la cascata di calcolo dei prezzi per un determinato contesto, ad esempio vendite dirette, canale partner o ecommerce. Definiscono la cascata di calcolo dei prezzi per un determinato contesto, ad esempio vendite dirette, canale partner o ecommerce.
- Gli elementi prezzi sono singole fasi di una procedura. Ogni elemento è di tipo Rettifica manuale, Pianificazione sconti, Listino prezzi, Prezzi basati sugli attributi e così via. Vedere Utilizzo degli elementi prezzi nelle procedure.
- I piani procedurali definiscono la procedura di determinazione dei prezzi da applicare in base al contesto. Questi piani abilitano logiche di calcolo dei prezzi diverse per ogni canale, segmento di clienti o categoria di prodotto senza regole di duplicazione.
- I prezzi basati sugli attributi calcolano un prezzo diverso per un prodotto in base ai suoi attributi di configurazione senza richiedere SKU o condizioni delle regole di prezzo separate per ogni variante.
- I prezzi di utilizzo o consumo sono un motore di valutazione nativo per i modelli di utilizzo basati sul consumo e a livelli. Non è richiesto alcun codice personalizzato.
- I prezzi degli articoli contrattati forniscono sostituzioni dei prezzi specifiche dell'account o del contratto utilizzando oggetti Gestione del reddito standard, che sostituiscono i record personalizzati ContractedPrices di CPQ.
I prezzi in Gestione del reddito sono flessibili e più facili da gestire rispetto alla cascata dei prezzi CPQ. Di seguito è riportato un esempio di cascata di prezzi per una voce preventivo in Gestione del reddito.
Il prezzo unitario netto di 10.260 viene calcolato applicando questi sconti in sequenza al prezzo di listino di 15.000.
| Fase | Descrizione | Calcolo | Risultato |
|---|---|---|---|
| 1 | Prezzo di listino | Nessuno | 15.000 |
| 2 | Sconto basato sugli attributi | 15,000 − 3,000 |
12000 |
| 3 | Rettifica del 5% basata su bundle | 12,000 − (12,000 × 5%) = 12,00 − 600 |
11,400 |
| 4 | Sconto volume del 10% | 11,400 − (11,400 × 10%) = 11,400 − 1,140 |
10,260 |
Riprogettazione e migrazione del processo di calcolo dei prezzi
La logica dei prezzi CPQ raramente viene migrata senza modifiche. I due sistemi definiscono i prezzi in modi diversi. Una traduzione diretta da regola a regola spesso produce risultati errati perché le regole CPQ dipendono dall'ordine di esecuzione, che non ha un equivalente diretto nelle procedure di calcolo dei prezzi di Gestione del reddito.
Il passaggio dal motore di regole sequenziali di CPQ al modello di procedura di calcolo dei prezzi di Gestione del reddito è quindi un'opportunità per semplificare il processo di calcolo dei prezzi dell'azienda. La domanda chiave non è come replicare le regole CPQ esistenti, ma quali risultati di calcolo dei prezzi sono effettivamente necessari per l'azienda e il modo più chiaro per esprimerli.
- Controllare tutte le regole di prezzo attive e la logica QCP prima di iniziare qualsiasi lavoro di migrazione. Utilizzare strumenti basati sull'intelligenza artificiale, ad esempio Forsys o IdeaHelix, per generare rapporti di spiegabilità su tutte le regole di prezzo CPQ e la logica QCP. Prima di riprogettare ogni regola, è importante capire l'intento e lo scopo aziendale di ogni regola, che si tratti di prezzo di listino, sconto, protezione del margine o rettifica del canale.
- Classificare ogni regola CPQ nell'equivalente Gestione del reddito. Le rettifiche di prezzo semplici diventano elementi di prezzo e la logica trasversale complessa diventa Flussi personalizzati o Apex all'interno della procedura.
- Razionalizzare le regole sui prezzi che si sono accumulate nel tempo senza una chiara proprietà. La migrazione è il momento giusto per mandare in pensione una logica che non è più rilevante dal punto di vista commerciale.
- Mappare i requisiti di prezzo specifici del canale per i canali diretti, partner e self-service ai piani procedurali in Gestione del reddito. Questa mappatura consente un singolo catalogo prodotti con prezzi appropriati al contesto anziché costrutti di prezzi separati per ogni canale.
- Se l'azienda si sta orientando verso la monetizzazione ibrida, configurare il consumo e i prezzi basati sull'utilizzo in Gestione del reddito. Le procedure di valutazione determinano il tasso netto finale per il consumo utilizzando regole e livelli specifici definiti nelle schede base, livello o tasso di attributo.
- Convalidare i prezzi ridisegnati confrontandoli con un pacchetto di preventivi curato, ovvero un insieme rappresentativo di preventivi storici di cui sono noti i prezzi di output. Se la procedura di gestione del reddito produce gli stessi risultati, la riprogettazione è corretta.
- Per le organizzazioni con più valute, eseguire la migrazione e convalidare una valuta alla volta per evitare l'arrotondamento tra i valori delle voci del listino prezzi.
Prima di impegnarsi in una strategia di migrazione, investire tempo in un controllo della logica dei prezzi. Il volume e la complessità della personalizzazione dei prezzi è uno dei predittori più forti dell'impegno di migrazione complessivo.
Motore prezzi singolo in tutti i canali
L'architettura API-first di Gestione del reddito affronta la sfida dell'integrazione della proliferazione della logica dei prezzi nei canali. Molte aziende finiscono per mantenere regole di prezzo separate per le vendite dirette, i portali partner e i canali self-service, creando tre versioni della stessa realtà che divergono nel tempo e causano incoerenza per i clienti.
Ogni operazione sul reddito in Gestione del reddito è esposta come API. Pertanto, la stessa logica di prodotto, prezzo e configurazione che alimenta l'interfaccia utente Salesforce può essere utilizzata da un portale partner, un'esperienza di ecommerce self-service o un flusso di acquisto interno ai prodotti senza duplicare le regole. È possibile avere un unico catalogo e un unico motore di calcolo dei prezzi che funziona per ogni canale.
È possibile integrare strumenti di visualizzazione di terze parti, ad esempio ThreeKit e RenderDraw, per la configurazione visiva dei prodotti.
