Il forecasting in Dynamics 365 Sales trasforma le opportunity aperte in una previsione di ricavo aggregata e navigabile lungo la gerarchia commerciale. Come Customer Experience Analyst il tuo compito non è “prevedere” a mano, ma configurare il modello corretto per lo scenario di vendita e garantire che i dati di pipeline si riversino nelle colonne giuste.
Scegliere il forecast type
Quando crei una nuova configurazione, il primo bivio architetturale è il tipo di forecast, che determina la dimensione di aggregazione:
- Org chart / hierarchy-based: aggrega lungo la gerarchia dei venditori (manager → subordinati). È la scelta di default per misurare il target rispetto alla quota per team.
- Product-based: aggrega per prodotto o famiglia di prodotti, utile quando la conversazione di forecast è “quanto venderemo di X”, non “quanto venderà Marco”.
- Territory-based: aggrega lungo la territory hierarchy, indicato per organizzazioni strutturate per area geografica.
La scelta non è cosmetica: puoi avere più forecast attivi in parallelo (uno org-chart per la quota, uno product per il supply planning), ma ciascuno richiede la propria gerarchia sorgente correttamente popolata.
Prerequisiti
Prima di attivare qualsiasi configurazione servono due fondamenta:
- Gerarchia di sicurezza: per l’org-chart forecast la relazione manager sugli utenti (o una position hierarchy) deve essere definita, perché è ciò che disegna righe e drill-down. La visibilità segue la gerarchia: un manager vede i propri numeri e quelli dei subordinati.
- Valute aggiornate: gli exchange rate della base currency devono essere corretti, altrimenti le opportunity in valuta estera vengono convertite con tassi errati e i totali risultano distorti.
Configurare colonne, layout e adjustment
Il cuore della configurazione è la definizione delle colonne:
- Rollup column: somma gli importi delle opportunity in base alla forecast category (es. la colonna Committed raccoglie le opportunity marcate come Committed).
- Simple column: valore inserito manualmente, tipicamente la quota.
- Computed column: formula fra altre colonne (es. gap = Quota − Committed).
Definisci l’entità di rollup (di norma Opportunity), il campo data (Estimated close date) che colloca l’opportunity nel periodo, e il campo importo da aggregare. Nel layout imposti la ricorrenza (mensile/trimestrale) e il range di periodi.
Puoi abilitare gli adjustment: venditori o manager possono sovrascrivere manualmente un valore di forecast (con nota), senza toccare le singole opportunity — utile per incorporare conoscenza non ancora in CRM. Gli snapshot ricorrenti vanno pianificati per catturare periodicamente lo stato del forecast e alimentare l’analisi dei trend (Forecast vs Actual nel tempo); senza snapshot ricorrenti perdi lo storico.
La forecast category sull’opportunity
Il collante fra pipeline e forecast è il campo Forecast Category sull’opportunity, con valori: Pipeline, Best Case, Committed, Won, Omitted. Sono questi valori — non lo stage del business process flow — a decidere in quale colonna di rollup finisce l’importo. Quando un’opportunity viene chiusa come vinta, la categoria passa automaticamente a Won; le altre transizioni sono tipicamente guidate dal venditore o da regole/automazioni.
Punto critico: dopo aver modificato una configurazione (colonne, gerarchia, mapping) devi eseguire un recalculation perché i valori si riallineino — le modifiche non sono retroattive in automatico.
Trappole tipiche d’esame
- Scenario: un’opportunity è nello stage “Propose” del BPF ma non compare nella colonna Committed. → La colonna di rollup dipende dalla forecast category, che è indipendente dallo stage/phase della pipeline: vanno impostati separatamente.
- Scenario: serve prevedere il ricavo per linea di prodotto, non per venditore. → Configura un forecast di tipo product-based, non org-chart.
- Scenario: dopo aver aggiunto una colonna computed i totali non cambiano. → Manca il recalculation: le modifiche di configurazione richiedono un ricalcolo esplicito.
- Scenario: un manager regionale deve vedere i forecast del suo team ma non di altre aree. → La visibilità deriva dalla gerarchia di sicurezza (manager/position hierarchy), che deve essere corretta prima dell’attivazione.
- Scenario: si vuole confrontare l’andamento del Committed settimana su settimana. → Servono gli snapshot ricorrenti pianificati; senza, non esiste storico da comparare.