Non costruire, integra: una guida all'integrazione con il CRM

Diciamo che stai lavorando per una startup che vende robot in tutti i settori. Ricevi ordini da una varietà di clienti e un team operativo valuta gli ordini e collabora con fornitori di terze parti per fornire ai tuoi clienti il ​​robot giusto.

Costruire l'MVP è stato stressante ma anche molto divertente. I tuoi investitori sono entusiasti e ti inondano di soldi. Inizia la fase successiva. Hai bisogno di maggiore visibilità sulla redditività e vuoi acquisire clienti più grandi che necessitano di una fatturazione più sofisticata. Allo stesso tempo, hai una roadmap del prodotto piuttosto sofisticata per consentire la vendita di robot con margini più elevati. Le risorse sono scarse, ma devi comunque assicurarti di mantenere l'azienda in funzione.

Come spesso predicato per le aziende più piccole, concentrarsi sulle cose in cui sei bravo è un'ottima regola pratica. Ma che dire di tutte le aree che fanno funzionare le operazioni quotidiane della tua azienda? Certamente non vuoi costruire un sistema di gestione delle relazioni con i clienti (CRM) o un sistema di contabilità. Dopotutto, ci sono molti prodotti là fuori che risolvono tutti i problemi. Ma come funzioneranno questi sistemi insieme al tuo sistema di ordini esistente?

È qui che l'integrazione di terze parti è utile. Quindi, tuffiamoci e vediamo se possiamo evitare alcune insidie ​​comuni.

Integrazione CRM

Sia che tu stia effettuando vendite low-touch (marketing dei contenuti, annunci sui social media o newsletter) o vendite high-touch (chiamate a freddo, partecipazione a conferenze o follow-up con i clienti esistenti tramite telefono), un sistema CRM può darti un sacco di visibilità su come stai andando con i clienti esistenti e quanto successo hai con i nuovi clienti convincenti.

Spesso la scelta di un sistema CRM è per lo più lasciata al reparto vendite e marketing. In generale, non c'è niente di sbagliato in questo. Dopotutto, queste persone sanno come aumentare le entrate e hanno bisogno del miglior supporto disponibile. Ma anche il miglior software non vale nulla se non funziona correttamente insieme al sistema di ordinazione dei robot.

Includi il tuo dipartimento tecnico nella decisione

Che si tratti del CTO o di un ingegnere dedicato, tienili aggiornati dall'inizio. È molto probabile che ti forniscano maggiori informazioni su come i due sistemi lavoreranno insieme in futuro.

E una parola per gli ingegneri: mantieni una mente aperta verso soluzioni di terze parti. È facile ignorarli perché la loro API non è la migliore o la loro interfaccia utente è brutta. Tuttavia, può essere molto gratificante trovare soluzioni eleganti attorno ai sistemi esistenti.

Tuttavia, ci sono un paio di argomenti di cui può essere utile parlare prima di prendere una decisione. Argomenti generali come "Ne abbiamo davvero bisogno?" devono essere affrontati. Ma è anche una buona idea avere già un'idea di quale sia la portata. È necessaria una sincronizzazione bidirezionale o il sistema di terze parti seguirà semplicemente il sistema degli ordini? Una volta eliminato l'ambito, è necessaria anche una discussione tecnica sui dettagli di implementazione come webhook o valutazione dei limiti dell'API.

Hai bisogno di un'integrazione personalizzata?

Quando si tratta di integrazione, non sorprende che esistano già piattaforme esistenti che promettono di risolvere alcuni dei problemi che probabilmente incontrerai. Attualmente, Zapier e IFTTT sono i più promettenti.

A seconda del problema che stai cercando di risolvere, il tuo sistema di ordinazione dei robot potrebbe non essere nemmeno coinvolto nell'integrazione. Supponiamo che tu stia gestendo i tuoi abbonati alla newsletter con un sistema CRM come Salesforce o HubSpot e desideri solo un modo più conveniente per contattarli tramite un fornitore di servizi di posta elettronica come Mailchimp, Zapier ha tonnellate di integrazioni esistenti per aiutarti in questo. Da questo momento, scegliere un provider che disponga di un connettore Zapier è un buon modo per andare avanti.

E anche se si tratta di integrare dati personalizzati (robot ordinati e il loro prezzo), Zapier Webhooks può fungere da intermediario per la tua integrazione.

Se invece stai già inviando dati a terzi, perché non inviarli direttamente al sistema CRM? Più dati vuoi sincronizzare, più utile sarà un'integrazione diretta.

Il che mi porta al punto successivo.

Hai bisogno della sincronizzazione bidirezionale?

Di solito, un'integrazione inizia con un semplice requisito come Possiamo portare tutti i nostri clienti nel nostro sistema CRM? , in genere combinato con i valori dei singoli ordini di robot, semplificando l'utilizzo degli strumenti di segmentazione dei clienti.

Tuttavia, prima o poi, potrebbe accadere che le persone vorranno utilizzare gli strumenti di gestione dei contatti offerti in genere da una suite CRM. Questi includono funzionalità come la deduplicazione, la modifica dei dettagli di contatto con i dati dei social media, la normalizzazione degli indirizzi di spedizione o semplicemente l'eliminazione dei vecchi contatti.

Modificare i contatti in un sistema CRM molto probabilmente significherà che dovrai modificare i dettagli di contatto in un altro sistema, ovvero le modifiche devono andare in entrambi i modi.

Lo sforzo di implementazione per questo è ben oltre una semplice sincronizzazione unidirezionale, quindi questo è un ottimo punto per pensare a come si desidera utilizzare strategicamente un nuovo sistema.

Come verrai informato delle modifiche dal CRM?

Se decidi di avere una sincronizzazione bidirezionale, c'è una domanda di follow-up: come fai a sapere che qualcosa è cambiato sul lato CRM?

La maggior parte dei fornitori di sistemi dispone di strumenti per questo, ma il migliore per le modifiche immediate sono i webhook, essenzialmente un sistema di notifica HTTP che può essere configurato per informarti sulle modifiche rilevanti (per alcuni sistemi, anche campo per campo). .

Se il sistema non offre webhook, controlla almeno se riesci a ottenere un elenco di tutte le entità che sono state aggiornate di recente. In questo modo, non devi passare attraverso tutti i contatti e le offerte solo per aggiornare i tuoi dati. Ma tieni presente che dovrai eseguire il polling del sistema a intervalli regolari.

In questo caso, il tuo sistema di ordini continuerebbe a cambiare e creerebbe dati tramite una chiamata API sul sistema CRM. Ma tutte le modifiche dal sistema CRM verrebbero esaminate in un intervallo definito.

Ciò che vale la pena notare è che gli aggiornamenti saranno limitati a questo intervallo e possono portare a un'incoerenza temporanea dei dati. Ad esempio, quando sincronizzi solo una volta al giorno dal tuo sistema CRM al tuo sistema di ordini, i dati che stai guardando nel tuo sistema di ordini possono risalire a 24 ore prima.

A seconda delle funzionalità offerte dal sistema, l'attività di integrazione può variare in termini di complessità e tempo di implementazione. Assicurati di controllare in anticipo ciò che il sistema offre e ricontrolla il piano che intendi acquistare. Ad esempio, alcuni sistemi CRM offrono webhook nei livelli più pagati.

Un esempio qui è il CRM di HubSpot, che offre webhook in generale ma la funzione webhook è disponibile solo nel loro pacchetto Enterprise. Gli strumenti di contabilità Zoho Books offriranno cinque flussi di lavoro automatizzati (che includono webhook) nel livello più basso.

I tuoi dati sono in buona forma?

Quando si tratta di creare set di dati in un sistema esterno, è bene sapere che aspetto hanno i dati nel proprio sistema. Fortunatamente, non ci sono molti modi diversi per presentare contatti e offerte, ma un campo che causa sempre problemi è il campo e-mail.

Sistemi diversi hanno idee diverse su cosa sia un indirizzo e-mail valido, ed ecco un avviso spoiler: i tuoi clienti potrebbero averti fornito indirizzi e-mail non validi di tutti i tipi. Molti sistemi CRM rifiuteranno la creazione di un contatto con un indirizzo email non valido (e, naturalmente, il provider CRM definisce cosa è valido e cosa no).

Suggerimento: se possibile, sincronizza solo gli indirizzi email confermati sul tuo CRM. Questo ti farà risparmiare un sacco di dolore a lungo termine.

Limitazioni API

Infine, le limitazioni dell'API devono essere affrontate il prima possibile.

Supponendo che esista un'API (che è fondamentalmente un must per qualsiasi integrazione), è utile esaminare i limiti dell'API. La maggior parte delle startup può far fronte ai limiti API di base della maggior parte dei sistemi CRM. Ad esempio, HubSpot offre 250.000 chiamate API in un periodo di 24 ore anche nel livello gratuito. D'altra parte, limita anche le chiamate a 10 al secondo (100 se usi OAuth). Salesforce, leader di mercato, ne consente solo 100.000 ogni 24 ore, ma si offre di acquistarne di più.

La maggior parte delle volte rientrerai facilmente in questi limiti, ma c'è una cosa da considerare: cosa mi dici della tua corsa iniziale? All'inizio, spingerai molti contatti e offerte sul tuo CRM (e possibilmente più volte in caso di problemi). Di conseguenza, potresti raggiungere il limite giornaliero dell'API.

Per mitigare questo problema, puoi testare con un piccolo set di dati e aumentare lentamente il numero durante l'implementazione per rimanere entro il limite dell'API. Per la migrazione iniziale, pianificala su più giorni o in un fine settimana. In alternativa, contatta il fornitore e comunicagli le tue intenzioni. Quando sei nella fase di valutazione (e non hai ancora pagato per il sistema), potrebbero essere disposti ad aumentare un po' la tua quota API.

Implementazione CRM

Diciamo che siete tutti d'accordo. Hai scelto un ottimo strumento CRM e gli ingegneri sono fiduciosi che possa essere integrato piuttosto facilmente. Hai deciso di definire l'ambito per inviare solo i dati dei clienti e gli ordini di robot accettati. Pertanto, la sincronizzazione bidirezionale non è necessaria e le modifiche agli indirizzi verranno gestite solo nel tuo sistema di ordini.

Ci sono ancora un paio di buone pratiche da seguire durante la fase di implementazione.

Prova tutto in un ambiente di prova

Nella maggior parte dei casi, il sistema CRM verrà utilizzato solo dopo che l'integrazione è stata completata e pronta per l'uso. Per questo caso d'uso, può sembrare interessante utilizzare solo il sistema di produzione durante lo sviluppo. Dopotutto, non ci sono dati di produzione che potresti influenzare. Una volta terminato lo sviluppo, rimuoverai semplicemente tutti i dati di test che hai creato, eseguirai una migrazione iniziale e indirizzerai il tuo sistema di ordini a questo ambiente.

Ci sono un paio di problemi con questo approccio:

1. Stai solo prendendo a calci la lattina lungo la strada. Anche se il tuo go-live procede senza intoppi, prima o poi ci sarà una richiesta di funzionalità per modificare parte della tua integrazione. Dato che la richiesta di funzionalità è abbastanza grande, probabilmente avrai bisogno di un'altra fase di test. A questo punto, un sistema di test separato è inevitabile; in caso contrario, potresti finire per incasinare i dati di produzione. Allora perché aspettare con l'installazione fino a quando non ti viene chiesto di implementare la prima funzionalità?

   

2. Si finisce con una configurazione disordinata. È molto probabile che il tuo sistema CRM necessiti di una sorta di configurazione per soddisfare le esigenze del tuo sistema di ordini. Potrebbe essere necessario modificare i nomi degli stati, in genere è necessario creare campi personalizzati e così via. Poiché la maggior parte degli sviluppatori dovrà abituarsi al sistema CRM, verrà aggiunta una configurazione che non sarà necessaria a lungo termine. In realtà, questa configurazione inutilizzata non viene rimossa in seguito e potrebbe persino rimanere nel tuo CRM per sempre. Forzando il passaggio aggiuntivo di replicare la configurazione dal sistema di test alla produzione, molto probabilmente ti ritroverai con una configurazione più snella sul tuo sistema di produzione.
   
   Va notato che questo può anche giocare a tuo svantaggio se ti dimentichi di copiare la configurazione dal tuo test al tuo sistema di produzione e finirai con errori di produzione.
   
   Sebbene ci siano alcuni sistemi CRM che ti aiuteranno a confrontare e copiare elementi di configurazione, in generale sarà utile annotare le tue configurazioni per non dimenticare gli elementi cruciali. La maggior parte dei CRM fornisce un'API alla propria configurazione, quindi è possibile automatizzare questo passaggio.

3. Corri un rischio maggiore di inquinare i dati di produzione. Immagina per un secondo due sviluppatori che lavorano su un'integrazione. Hai già un sistema di staging del sistema di ordinazione dei robot. Anche questo staging è collegato al tuo CRM. Una volta spedita l'integrazione, dovrai ricordarti di disconnettere tutti e tre i sistemi, altrimenti potresti finire per creare dati di test sul tuo (ora) CRM di produzione.

Tutti questi problemi possono essere evitati sviluppando fin dall'inizio un sistema di test. La produzione viene introdotta solo alla fine, subito prima che tutto diventi attivo. In questo modo, si ottiene una configurazione pulita, non si corre il rischio di dimenticare di disconnettere i sistemi locali e si ha un avviso quando si implementano nuove funzionalità.

Definisci l'ID per le entità corrispondenti

Ora iniziamo a scrivere il codice di integrazione effettivo. Prendiamo l'esempio della sincronizzazione dei contatti con un sistema CRM. Presumibilmente, dovrai creare nuovi contatti e aggiornare i contatti esistenti. Per distinguere una creazione da un aggiornamento, è necessario collegare le due entità. In questo modo, puoi verificare se il contatto nel tuo sistema esiste sul sistema esterno.

Sebbene sembri interessante utilizzare solo l'indirizzo e-mail (dopotutto, è un identificatore comune per un record di contatto), esiste una soluzione più generale: per ogni record, ti sincronizzi con un blocco di sistema esterno e un ID nel tuo database.

Quindi, modifica la tua tabella dei contatti con una colonna chiamata crm_id o external_id . Questo approccio ha un paio di vantaggi:

• Poiché si tratta di un ID, non cambierà (a differenza di un indirizzo e-mail o di un numero di telefono).
• Puoi vedere se è necessario creare o aggiornare l'entità senza prima eseguire una chiamata API (se il campo ID esterno è vuoto, puoi presumere che il contatto non esista).

Prima:

Dopo:

Ad esempio, supponiamo che tu sia uno sviluppatore Ruby on Rails che lavora su un'applicazione che deve sincronizzare clienti esistenti e nuovi con HubSpot.

Un esempio di codice semplificato potrebbe essere simile a questo:

 class HubspotSync def sync(customer) hubspot_return = if customer.hubspot_id.present? update(customer, customer.hubspot_id) else create(customer) end customer.update(hubspot_id: hubspot_return['companyId']) end private def create(customer) response = HTTParpty.post("https://api.hubapi.com/companies/v2/companies", map(company)) handle_response(response) end def update(customer, hubspot_id) response = HTTParpty.put("https://api.hubapi.com/companies/v2/companies/#{hubspot_id}", map(company)) handle_response(response) end def handle_response(response) raise RuntimeError, "Unexpected Status code: #{response.code}" if response.code >= 500 JSON.parse(response.body) end def map(company) # mapping code goes here { properties: [ name: 'name', value: company.name ] } end end

Nota come stiamo sfruttando il salvataggio dell'ID azienda restituito da companyId . Non solo ci aiuta a determinare se vogliamo aggiornare o creare un'azienda su HubSpot, ma possiamo anche vedere nella tabella del database quali entità sono già sincronizzate con HubSpot e quali mancano ancora.

Quando si tratta di mappare i campi, scegli lo stile libero

Ho visto progetti in cui l'implementazione è preceduta dalla creazione di un gigantesco foglio di calcolo Excel che definisce quali colonne vanno dove vanno nel sistema CRM, con annotazioni su come devono essere trasformati i dati.

In realtà, ci sono solo alcuni modi per rappresentare contatti e offerte. Quindi, invece di passare molto tempo a pensare a come esattamente vuoi mappare, perché non iniziare con un esperimento? Dai allo sviluppatore un po' di spazio per capire la mappatura, ma tieniti anche in contatto in modo che le domande possano sorgere presto.

Almeno per i campi di contatto generici (nome, indirizzo email, numero di telefono, indirizzo), la mappatura sarà molto semplice e le trasformazioni di solito sono banali.

Quando si tratta di mappare lo stato per le offerte, è utile un po' più di comunicazione (a volte, il primo stato è chiamato open , a volte new e, a volte, il modello di stato non corrisponde al 100%, quindi dovrai raggruppare gli stati insieme ). Invece di trovare la soluzione perfetta, guarda i tuoi dati attuali e guarda come si adatterebbero meglio al modello di dati del CRM. Dopotutto, sei un'azienda agile, giusto?

Nell'esempio sopra, puoi vedere un metodo map che converte il nostro modello Rails in un hash normale che è compreso da HubSpot. Per questo caso d'uso particolare, l'unico elemento sincronizzato è il nome. Per un utilizzo più avanzato, probabilmente vorrai includere più campi, ma per un ottimo risultato, inizia con un'ipotesi plausibile e comunica spesso con il lato aziendale per i dettagli.

Considera i tentativi

Scendiamo al livello più tecnico: implementare la sincronizzazione effettiva tra il tuo sistema e il CRM. È quasi scontato che l'integrazione avverrà tramite una connessione HTTP. La maggior parte dei sistemi fornisce un'API HTTP e tutti i linguaggi di programmazione ti permetteranno di effettuare chiamate HTTP molto facilmente.

Sfortunatamente, non importa quanti soldi spendi per un sistema CRM, alla fine non sarà raggiungibile. Questo accadrà ad un certo punto e non c'è nulla che tu possa fare al riguardo. Quindi, potresti anche tenerne conto quando stai sviluppando la tua integrazione.

Ciò significa in pratica: ogni volta che chiami un'API, assicurati che la chiamata venga ritentata in caso di problemi (codice di stato 500 dall'altra parte). L'implementazione dei tentativi è qualcosa che di solito viene fornito da librerie di terze parti della tua lingua preferita.

Oltre a riprovare, potresti prendere in considerazione la possibilità di registrare ciò che è successo esattamente. Ricevere una notifica su un errore che è già stato risolto al primo tentativo può essere frustrante.

Quindi, invece di inviare spam al tuo canale di errore con problemi risolti, registra tutti i callout con il numero di tentativi per avere un'idea dell'affidabilità del sistema, un sistema per il quale hai appena pagato un sacco di soldi.

Se prendiamo come esempio la classe che abbiamo creato e rimaniamo nel contesto di Ruby on Rails, possiamo semplicemente racchiudere la chiamata in un ActiveJob ed essere abbastanza certi che alla fine la chiamata avrà successo. Il metodo handle_response genererà un errore in caso di codice di stato imprevisto e ActiveJob tenterà di riprovare con un backoff esponenziale. Per una soluzione più avanzata, dovresti anche considerare i codici di stato 4xx in modo che venga impedito un nuovo tentativo e venga generato un messaggio di errore.

 class HubspotSyncJob < ApplicationJob def perform(customer) HubspotSync.new.sync(customer) end End

Assicurati che il sistema sia effettivamente utilizzato

OK, supponiamo che tu abbia spedito tutto. Sei super orgoglioso del tuo lavoro e il sistema diventa operativo. E adesso? Questo è solo l'inizio. Perché non importa quanti test stai facendo, ci saranno sempre bug e modifiche richieste.

Il problema è che non li scoprirai a meno che non usi effettivamente il tuo sistema. E questo accade per tutti i tipi di motivi: il reparto vendite è attualmente troppo impegnato per iniziare a usarlo, la strategia è cambiata o anche nuovi sistemi sono già in fase di valutazione.

Pertanto, al fine di evitare potenziali problemi a lungo termine, assicurarsi di aver eliminato tutti gli ostacoli che impedivano l'utilizzo del sistema in produzione. Comunica spesso tra i team per allineare i nuovi requisiti. E se scopri che il sistema non funzionerà per te, disattiva l'integrazione. Sembra duro e può sembrare molto frustrante, ma è meno frustrante del dover sempre risolvere i problemi di incoerenza dei dati e affrontare soluzioni alternative.

Avvolgendo

Alla fine, un progetto di integrazione è un progetto infernale e ci sono molte cose che possono andare storte. Non è molto popolare tra gli ingegneri per una serie di motivi, ma può essere gratificante vedere che un'implementazione ha un impatto positivo sulla produttività delle persone sedute accanto a te.

Quindi, per gli ingegneri, prova a capire le esigenze di un sistema esterno come un CRM o un sistema di fatturazione ponendo domande concrete come: in che modo questo prodotto ti semplificherà la vita? Hai considerato i concorrenti? Perché non funzionano?

Per tutti gli altri coinvolti: coinvolgi gli ingegneri il prima possibile, fidati di loro quando indicano linee rosse e non optare per un piano economico quando puoi vedere che l'implementazione dell'integrazione renderà molto più difficile il lunga corsa.