Come gestisce cinque tipi diversi di richieste dei clienti in un unico help desk?

01Il problema di business

Un produttore vende attraverso una rete di distributori indipendenti. Questi distributori hanno continuamente bisogno di qualcosa dal produttore, e le richieste non hanno tutte la stessa forma:

• Un ordine di acquisto da evadere ai prezzi concordati
• Una richiesta di preventivo per un elenco di componenti, con quantità e una data entro cui servono
• Una richiesta di nuovo prodotto — qualcosa che non è a catalogo e che richiede una verifica di fattibilità tecnica e l'approvazione di sei reparti interni prima di poter indicare un prezzo
• Una richiesta di certificazione del materiale per un lotto di produzione specifico, per completare il fascicolo di conformità di un cliente finale
• Una domanda o un reclamo generico che non rientra in nessuno dei casi precedenti

Prima del progetto, tutte e cinque arrivavano come email e telefonate a caselle di posta condivise. Nulla aveva un numero di riferimento, nessuno poteva rispondere a "a che punto è la mia richiesta?" senza chiedere a una persona, e non c'era modo di vedere quanto tempo avesse richiesto qualsiasi cosa.

Ciò che l'azienda ha chiesto era un help desk con:

• una sola coda e una sola serie di numeri di riferimento, così che qualsiasi richiesta possa essere citata in un'email;
• un ciclo di vita degli stati comprensibile a tutti, da nuovo fino a risolto;
• self-service per i distributori — chi invia una richiesta vede le proprie e nessun'altra;
• un thread di conversazione per ogni richiesta, con una separazione rigorosa tra ciò che vede il distributore e ciò che resta interno;
• un audit trail di chi ha modificato cosa e quando;
• e, solo per le richieste di nuovo prodotto, un'approvazione formale da parte di più reparti.

La tensione sta tutta nella combinazione. L'uniformità è desiderata per la coda. La differenziazione è necessaria nel contenuto: una richiesta di certificazione ha bisogno di un numero di lotto e di un numero di colata, e non sa che farsene di una data di consegna; una richiesta di preventivo ha bisogno di un insieme ripetuto di righe di componenti, che una domanda generica non ha mai.

02Perché l'approccio ovvio non funziona

Esistono due istinti iniziali, ed entrambi sono sbagliati in un modo che costa una ricostruzione.

Istinto uno: un'entità più un menu a tendina "Request Type"

È il riflesso, perché un menu a tendina è la cosa più economica da creare. Fallisce su un punto specifico e strutturale: il valore di un menu a tendina non può selezionare un modulo.

Coevera associa un layout di modulo modificabile a ciascun CustomEntityType. Non esiste alcun meccanismo con cui il valore di un campo personalizzato cambi il layout. Con un menu a tendina si ottiene quindi esattamente un modulo per tutti e cinque i tipi, con l'unione dei campi di ogni tipo — in questa implementazione sono 42 campi, contati sul modulo unificato nello spazio verificato il 2 settembre 2026, di cui circa una dozzina si applica a una data richiesta. Ai distributori viene chiesto un numero di lotto su un ordine di acquisto. Non c'è modo di rendere sensato il modulo.

Due ulteriori conseguenze, meno evidenti ma altrettanto dannose:

• Modificabilità. typeId viene impostato alla creazione ed è immutabile — lo impone la piattaforma, senza bisogno di automazioni di protezione. Un menu a tendina è modificabile da chiunque abbia accesso al campo, quindi un ordine di acquisto può diventare silenziosamente una richiesta di certificazione a metà del suo ciclo di vita, invalidando ogni report costruito su di esso.
• Ridondanza. Ogni record porterebbe allora due risposte alla stessa domanda — il suo vero typeId (che esiste che lei lo usi o no) e il suo menu a discesa — senza nulla che le mantenga coerenti.

Istinto due: cinque entità personalizzate separate

Il riflesso opposto: se i cinque tipi sono davvero diversi, li si modella separatamente. Si ottengono moduli puliti, e si perde tutto ciò che l'azienda aveva effettivamente chiesto:

• Cinque sequenze di numeri di riferimento invece di una serie condivisa
• Nessuna coda unica. "Mostrami tutto ciò che è aperto per questo distributore" diventa cinque viste elenco che una persona deve unire mentalmente
• Cinque insiemi di campi da mantenere allineati. Stato, gravità, richiedente, obiettivo SLA e una dozzina di altri sono comuni a tutti i tipi; ora esistono cinque volte e divergono
• Nessuna conversione sul posto. Una domanda generica che si rivela una richiesta di nuovo prodotto non può diventarlo — deve essere reinserita in un'altra entità, perdendo la sua cronologia e il suo numero di riferimento
• Ogni report è un'unione di cinque fonti, e ogni nuovo tipo la porta a sei

03Modello dati

Un'entità personalizzata, Case, con cinque record CustomEntityType al suo interno. Due entità personalizzate di supporto e tre estensioni di entità predefinite.

L'entità Case e i suoi sottotipi

Tutti i 42 campi personalizzati vengono creati una sola volta, sull'entità padre. I cinque sottotipi condividono quell'unico insieme di campi; la definizione del modulo di ciascuno seleziona il sottoinsieme pertinente. È questa la proprietà che rende conveniente l'intero pattern — 13 campi sono comuni a tutti e cinque i tipi e vengono definiti e mantenuti esattamente una volta.

Ovunque serva una distinzione per tipo — selezione del modulo, trigger delle automazioni, viste salvate, filtri API — il tipo viene indicato direttamente tramite typeId o type.name. Nessun wrapper, nessun campo personalizzato, nessuna logica di sincronizzazione.

Entità di supporto

L'entità Note è lo stesso pattern applicato una seconda volta, su scala ridotta: invece di un booleano personalizzato "è interna", la visibilità è portata da typeId. Due sottotipi, nessun flag da impostare in modo errato, e le automazioni filtrano direttamente sul tipo. Autore e data e ora provengono dai campi nativi del proprietario e della creazione — per nessuno dei due servono campi personalizzati.

Entità predefinite, estese

04Configurazione a livello di campo

42 campi personalizzati su Case, distribuiti in 13 comuni più una parte specifica per tipo:

La denominazione dei campi segue la convenzione della piattaforma — i campi personalizzati hanno il prefisso cf_, i campi a discesa e di lookup hanno il suffisso _id perché si risolvono in UUID di opzioni o di record anziché in valori letterali, e i campi di lookup prendono il nome dalla relazione che esprimono. I nomi dei campi in questo blueprint sono anonimizzati; forme, tipi e relazioni sono quelli realizzati.

Permessi sui campi per ruolo

Tre ruoli, e la separazione della visibilità è imposta a livello di campo anziché nascondendo elementi nell'interfaccia: None, Read o Full per ogni campo e ogni ruolo.

05Automazione e logica

Nove processi di automazione, tutti a livello di spazio. La regola che li organizza: un processo per ogni aspetto, filtrato per typeId. Poiché tutti e cinque i sottotipi condividono un'entità, ogni processo viene definito una sola volta e un nodo filtro all'inizio del grafo lo restringe ai tipi a cui si applica — invece di cinque copie quasi identiche.

Due pattern da riutilizzare

La protezione che scatta una sola volta. Per registrare "chi l'ha accettato per primo" senza sovrascriverlo a ogni aggiornamento successivo, filtri sul campo di destinazione vuoto e lo imposti sull'utente che agisce. La condizione rende la scrittura idempotente — nessun flag separato "è già stato eseguito?".

La proprietà resta dov'è. Il distributore che ha inviato il case rimane il proprietario del record per tutta la sua durata; l'analista interno è registrato in un campo di lookup separato. L'istinto è riassegnare la proprietà all'analista al momento dell'accettazione — ma è la proprietà a determinare l'accesso del distributore al proprio record. Riassegnarla toglierebbe al richiedente la visibilità sulla propria richiesta.

06Limiti e compromessi

I processi di approvazione non possono avere come destinazione un'entità personalizzata

Solo uno dei cinque tipi — le richieste di nuovo prodotto — richiede un'approvazione formale, da parte di sei reparti. Il pattern che funziona è un proxy su Quote:

1. Viene creato un case di tipo richiesta di nuovo prodotto.
2. Un processo genera un Quote collegato con un tipo di Quote dedicato, riservato alle approvazioni.
3. Il processo di approvazione viene eseguito su quel Quote, in modo nativo, con l'interfaccia di approvazione standard e l'audit trail — soglia, blocco del record e ruolo dell'approvatore configurati come su qualsiasi Quote.
4. Il Quote contiene un lookup verso il case; la piattaforma mantiene automaticamente il collegamento inverso.
5. Alla decisione, un secondo processo riporta l'esito nello stato del case.
6. Il Quote può poi essere archiviato.

Perché Quote e non Opportunity, dato che entrambi possono ospitare un'approvazione:

• Coerenza semantica. Una richiesta di nuovo prodotto è una decisione di prezzo — "possiamo produrlo, e a che prezzo?". È ciò che modella Quote. Opportunity intesa come trattativa è l'inquadramento sbagliato.
• Nessun inquinamento della pipeline. I proxy su Opportunity comparirebbero nella pipeline delle trattative e altererebbero previsioni e report sui ricavi. Un Quote resta nel proprio tipo di Quote, in disparte.
• Il prezzo viene registrato in modo nativo. Le righe del Quote sono il prezzo proposto — quindi non serve affatto un campo prezzo personalizzato sul case.
• Scadenza integrata. Quote ha una data di scadenza nativa, utile per limitare nel tempo una richiesta di approvazione.

Due campi rollup sul case mostrano lo stato del proxy — stato di approvazione e motivo del rifiuto — derivati dal Quote collegato anziché memorizzati. Per questi non serve alcuna logica di riscrittura; la piattaforma li aggiorna quando il Quote cambia.

Le note predefinite non potevano esprimere una visibilità a due livelli

Il requisito è un unico thread in cui alcune voci sono visibili al distributore e altre sono strettamente interne. La funzionalità di note predefinita non ha una dimensione di visibilità, quindi il thread è diventato un'entità personalizzata con due sottotipi. Un costo da dichiarare esplicitamente: il case ha quindi sia le note predefinite sia un thread di note personalizzato, e quelle predefinite devono essere tenute fuori dai moduli per evitare due posti concorrenti in cui scrivere.

I campi di testo libero non possono alimentare liste di distribuzione

Il campo dei contatti da notificare era inizialmente un'area di testo in cui digitare indirizzi email. È stato sostituito da un lookup a selezione multipla verso Contact, perché l'automazione non riesce a estrarre in modo affidabile gli indirizzi dal testo libero per costruire un elenco di destinatari. Se il valore di un campo deve essere elaborato e non soltanto letto, deve essere un riferimento tipizzato.

Altri vincoli incontrati in questa implementazione

• Un campo deve essere sul modulo per funzionare. I campi calcolati e i campi compilati dall'IA assenti dal layout del modulo di un record non fanno nulla, in silenzio — non calcolano e non segnalano errori. La presenza nel modulo è funzionale, non estetica.
• Le sequenze non si possono azzerare ogni anno. Il contatore nativo della sequenza si incrementa a ogni creazione e non prevede un azzeramento annuale. Un anno può essere inserito nel numero come prefisso, ma il contatore stesso prosegue senza interruzioni.
• I processi a livello di spazio richiedono credenziali autenticate tramite sessione. Le credenziali API ad accesso personale vengono rifiutate quando si scrivono processi dello spazio, anche se possono leggerli.

Lacune note in questa implementazione

Riportate anziché omesse:

• La riscrittura dell'approvazione gestisce solo il ramo approvato. Un proxy rifiutato lascia il case nel suo stato di lavorazione senza alcuna propagazione automatica — per l'esito rifiutato serve un filtro parallelo.
• Il processo delle note di audit si attiva a ogni aggiornamento del case anziché solo ai cambi di stato; ha bisogno di una condizione sui campi modificati per non generare più rumore.
• Le date obiettivo SLA vengono impostate manualmente. La loro derivazione dalla gravità è stata progettata e rinviata deliberatamente.

07Verifica

I progetti basati su sottotipi falliscono in silenzio — un modulo che si visualizza, un processo che segnala successo e un discriminante collegato alla cosa sbagliata. Ciò che è stato effettivamente verificato:

• Inventario dei campi riletto per ogni entità. Ogni campo è stato riletto dall'API dopo la creazione e confrontato con la specifica in base al nome API, non all'etichetta. Tre campi risultavano con nomi diversi dalla specifica, e uno non era stato creato affatto, in silenzio — nessuno dei due problemi era visibile dall'interfaccia.
• Numero e identità dei sottotipi. Confermato che sotto l'entità Case esistono cinque sottotipi e nessun sesto orfano — la trappola del predefinito automatico del §3 emerge proprio qui.
• Immutabilità del discriminante. Tentato di modificare typeId su un record esistente e confermato che la piattaforma lo rifiuta.
• Accesso ai campi per ruolo, testato come ciascun ruolo. Non letto dalla configurazione — effettuato l'accesso e confermato che i campi che devono essere invisibili a un distributore sono effettivamente assenti.
• Ogni processo confermato come attivo, e il suo grafo di nodi riletto. Due processi erano attivi ma si fermavano a nodi segnaposto — segnalavano successo e non facevano nulla. È questo il controllo che ha trovato la lacuna nella riscrittura dell'approvazione.
• Un passaggio completo per ogni sottotipo nell'interfaccia: creare, far avanzare nel ciclo di vita, confermare che note ed email arrivino, confermare che la vista del distributore mostri solo ciò che deve.

Cosa segnalerebbe una regressione: case che compaiono con un sottotipo vuoto o sbagliato; il campo dell'analista assegnato che cambia dopo la prima accettazione; note scritte come interne che raggiungono un distributore; richieste di nuovo prodotto senza un proxy di approvazione collegato.

Blueprint correlati

• Blueprint 003 — Come modella qualcosa per cui il suo CRM non ha un oggetto? — la decisione di collocazione che questo blueprint applica: campo, sottotipo, record correlato o nuova entità.
• Blueprint 004 — Come può impedire che preventivi e sconti vengano inviati prima che qualcuno li approvi? — il processo di approvazione che questo blueprint aggira con un Quote proxy, e cosa blocca effettivamente la soglia.
• Blueprint 006 — Come imposta una numerazione dei documenti che resista alla produzione? — l'unica serie di numeri di riferimento su cui funziona la coda, e cosa le fa un record eliminato.
• Blueprint 011 — Come mantiene gestibili centinaia di automazioni del CRM? — un processo per ogni aspetto, ciò che mantiene leggibile anche un anno dopo l'automazione filtrata per typeId.