CRM per Tecnologia

Come si vende davvero la tecnologia?

La richiesta in entrata di una software house è raramente una telefonata. È un account di prova creato alle 23:10 da qualcuno con un indirizzo aziendale, che si è registrato anche da due concorrenti; un modulo "richiedi una demo" compilato da un articolo di confronto; o il messaggio di un partner che ha incontrato un potenziale cliente a una fiera. La persona è abbastanza tecnica da valutare da sola e abbastanza impegnata da aver dimenticato tutto entro giovedì. Chi risponde per primo con qualcosa di utile — una risposta che funziona, uno slot di demo, un caso cliente simile — ottiene il secondo colloquio; gli altri restano con una prova che scade in silenzio.

L'evidenza sulla velocità è vecchia e senza sfumature: lo studio della Harvard Business Review su 2.241 aziende ha rilevato che rispondere entro un'ora rendeva un lead quasi sette volte più probabile da qualificare rispetto ad aspettare anche solo un'ora in più, e che il tempo medio di risposta era di 42 ore. Le aziende tecnologiche non sono più lente della media; sono semplicemente quelle in cui il fondatore fa ancora le vendite tra un rilascio e l'altro.

La seconda forma è la seconda vendita. In un modello ad abbonamento o a canone di manutenzione, vincere la trattativa è l'inizio del ricavo, non la fine. Il cliente che ha aperto quattro ticket nel primo mese e ne ha visti tre gestiti in ritardo non rinnova, e nessun report di pipeline dirà perché, perché la pipeline ha smesso di guardare a "vinta". Assistenza e vendita devono stare sulla stessa scheda.

La pipeline da cui consigliamo di partire

Ogni fase è un fatto verificabile. "Interessato" e "caldo" non sono fasi; una prova creata e una demo effettuata lo sono.

Per una società di servizi IT o un system integrator la forma è la stessa con due differenze: "call di analisi" sostituisce "demo", e "offerta inviata" porta una stima di progetto anziché un prezzo di abbonamento. Se vendete sia prodotto sia servizi, date a ciascuno la propria pipeline; Starter ne include due, Growth cinque, Business dieci.

I campi utili su un lead tecnologico

Il layout della scheda lead si configura per ruolo: il commerciale vede i campi di valore e di prova, l'operatore di assistenza vede il referente tecnico e i ticket aperti, e nessuno scorre quaranta campi. Anche i prodotti hanno i propri campi personalizzati — livello del piano, periodicità di fatturazione, postazioni incluse — così un'offerta si costruisce dal catalogo invece di essere digitata.

Prove, demo e il problema della prova ferma

Una prova che nessuno da parte vostra ha toccato entro il terzo giorno è, statisticamente, già persa. Il webhook dei lead accetta una semplice richiesta HTTP dalla vostra applicazione, quindi un nuovo account di prova crea un lead nell'istante della registrazione, con piano, fonte e campi di campagna allegati. Da lì in poi il lavoro è pianificare, non ricordare.

1. Giorno 0 — responsabile e primo contattoLa distribuzione per canale assegna il lead a rotazione; un'automazione invia il primo messaggio nella lingua del lead e crea un'attività "chiamare entro 4 ore lavorative".
2. Giorno 3 — la verificaUn'automazione su data legata al campo "inizio prova" apre un'attività per il responsabile: la prova ha fatto qualcosa? La risposta è una nota e un cambio di fase, non una sensazione.
3. Demo — fissata dalla conversazioneUn appuntamento con data, presentatore e prospect; i promemoria partono via WhatsApp, SMS o e-mail; l'esito segna presente o assente e sposta la fase.
4. Giorno 12 — l'avviso di scadenzaDue giorni prima della fine della prova, un'attività e un messaggio; una prova che scade senza colloquio va in Persa con il motivo "nessun contatto", che è un motivo che si può correggere.

Il report sui tempi di risposta misura la prima risposta in minuti lavorativi secondo il calendario dei turni, quindi la registrazione delle 23:10 gestita alle 9:05 conta cinque minuti e non dieci ore, e il commerciale che risponde sempre in quaranta minuti compare accanto a quello che risponde in quattro.

Ticket: l'assistenza come strumento di retention

Il modulo ticket è il desk di assistenza dei vostri clienti dentro il CRM: un cliente apre un ticket via e-mail o dal modulo, oppure il vostro team ne crea uno da una conversazione WhatsApp, e il ticket vive sulla stessa scheda cliente della trattativa che lo ha fatto firmare. Un ticket ha stato, priorità, assegnatario e thread di messaggi; l'assegnazione invia una notifica; il manager vede la coda per persona e per anzianità.

Tre cose fanno sì che il modulo funzioni in un'azienda tecnologica invece di limitarsi a esistere:

Una scheda, due storie

L'account manager che apre il colloquio di rinnovo vede i dodici ticket del trimestre scorso prima che il cliente li nomini. L'operatore di assistenza vede il piano, le postazioni e chi ha venduto.

Smistamento per regola, non a voce

Un'automazione assegna i ticket per prodotto, per livello di cliente o a rotazione nel team di assistenza, e rinotifica l'assegnatario quando un ticket resta senza risposta oltre un tempo che stabilite voi.

Il carico di ticket come segnale commerciale

Un report incrociato ticket per cliente per mese, accanto al valore delle trattative, è l'allarme precoce di abbandono di cui un'attività ad abbonamento ha bisogno e che raramente ha.

Vale la pena essere precisi su cosa non è: non ci sono timer di SLA contrattuali né catene di escalation per sforamento. Ci sono priorità, anzianità, regole di assegnazione e report — quello che la maggior parte dei team sotto le cinquanta persone usa davvero.

Le automazioni che si ripagano

Un'automazione è una regola con un trigger e una o più azioni. Le regole di fase scattano quando un lead entra in una fase; le regole di sistema sorvegliano date, inattività e messaggi in arrivo. Il catalogo comprende assegnare un responsabile, inviare un messaggio o un'e-mail, creare un'attività, modificare un campo, aggiungere un tag e spostare la fase, e ogni esecuzione viene registrata con il suo esito.

Commerciale, assistenza, sviluppo: chi vede cosa?

I ruoli decidono quali moduli una persona può usare e cosa può farci — vedere, creare, modificare, eliminare, esportare — per entità. L'ambito dati decide di chi vede le schede: le proprie, quelle del reparto o tutte. I reparti formano un organigramma; un manager vede ciò che vede il suo reparto.

Commerciale

I propri lead e trattative più i non assegnati; vede e modifica, non elimina né esporta; vede i prezzi e la propria provvigione, non quelle degli altri.

Direttore commerciale

Ambito di reparto sul commerciale; riassegna, esporta, vede i report di pipeline e di tempi di risposta.

Operatore di assistenza

I ticket e le schede cliente dietro di essi; la casella condivisa; niente pipeline, niente finanza.

Sviluppatore

I ticket assegnati a lui, la scheda cliente in sola lettura; nient'altro. La maggior parte degli sviluppatori vuole esattamente questo.

Fondatore / amministratore

Tutto, compresi finanza, registro attività e impostazioni.

Il registro attività annota chi ha visualizzato, modificato, riassegnato o esportato quale scheda — è la risposta quando un cliente chiede chi ha avuto accesso ai suoi dati, ed è ragionevole averla prima che un questionario di sicurezza la chieda.

Una settimana in una software house di dodici persone

1. Lunedì — le registrazioni del fine settimanaGià assegnate dalla distribuzione; ogni commerciale chiama la propria lista dal softphone, inserisce postazioni e strumento attuale, sposta la fase.
2. Martedì–giovedì — le demoFissate dalla conversazione, ricordate in automatico, segnate "presente"; le offerte costruite dal catalogo prodotti e inviate in giornata.
3. Ogni giorno — la coda dei ticketSmistata a rotazione, i più vecchi prima; uno sviluppatore prende i due escalati; il cliente vede le risposte nel thread che ha aperto.
4. Venerdì — la lista dei fermiLe offerte senza movimento da dieci giorni, portate a galla dall'automazione; una chiamata ciascuna, un motivo di perdita onesto dove serve.
5. Fine mese — i due reportPipeline per fase e fonte; ticket per cliente per mese. Entrambi su uno schermo, entrambi esportabili.

Servizi IT e system integrator: il progetto dopo la trattativa

Un system integrator o una società di servizi IT vende un progetto, non un piano. La pipeline finisce a "vinta" e lì comincia il lavoro: una lista di attività con responsabili e date, milestone, ore e costi. Nel piano Business una trattativa vinta può aprire un progetto con le sue attività, e le entrate e le uscite della trattativa ne mostrano la redditività — la stima contro ciò che è davvero costato in persone e licenze.

• Le attività ricorrenti coprono i contratti di manutenzione: una finestra di aggiornamento mensile, una revisione trimestrale, un rinnovo licenze annuale, ciascuno genera la propria attività alla scadenza.
• I prodotti con prezzo di costo coprono licenze e hardware rivenduti; quando la trattativa è vinta il costo viene registrato in automatico e il margine sulla rivendita diventa visibile.
• I ticket sotto contratto restano sulla scheda cliente, così l'account manager vede il carico di assistenza quando arriva il colloquio di rinnovo.

I numeri che un fondatore o un direttore commerciale deve guardare

• Il tempo di prima risposta in minuti lavorativi, per commerciale — il numero che predice le demo più di qualsiasi altro.
• Il tasso registrazione → demo e demo → offerta, per fonte — quali campagne producono acquirenti e non solo account.
• I giorni in "Offerta inviata" — la perdita; se crescono, qualcuno non sta seguendo.
• Trattative vinte e valore mensile per commerciale per mese — con l'imbuto dietro.
• Ticket per cliente al mese e anzianità dei ticket per assegnatario — il segnale di retention, accanto al ricavo che protegge.
• Motivi di perdita per prodotto — l'input più economico per la roadmap di prodotto.

Tutto questo viene dal generatore di report incrociati da Growth in su: righe, colonne, una misura e un filtro, salvati ed esportati in CSV.

Cosa non è

Non è un issue tracker per gli sviluppatori: non ci sono sprint, repository, release né integrazioni con gli strumenti di sviluppo. I ticket sono conversazioni con il cliente con uno stato e un responsabile; il bug dietro un ticket appartiene al vostro strumento di sviluppo, e il ticket ne porta il riferimento in un campo.

Non è un motore di fatturazione per abbonamenti: registra il valore delle trattative, entrate, uscite e provvigioni, ma non addebita carte, non emette fatture ricorrenti e non gestisce i solleciti. E i backup giornalieri automatici dello spazio di lavoro non fanno attualmente parte del servizio; esportate ciò che dovete conservare.

Quando smette di funzionare

Quale piano è adatto?

Una startup di due fondatori che vende da sola gira su Starter. Un'azienda con un team di assistenza, più di una manciata di prove a settimana e sviluppatori che dovrebbero vedere solo i ticket finisce su Growth — per ticket, automazioni e ruoli prima di tutto. Le società di servizi che hanno bisogno di progetti e di margine per commessa passano a Business. Vedi la pagina dei prezzi e le pagine ticket e automazioni, i due moduli che reggono il carico.