Comunicații omnicanal pentru dealeri: un singur istoric al clientului

Răspuns scurt

Comunicarea omnicanal a dealerului înseamnă că interacțiunile aprobate prin telefon, e-mail, web, platforme de anunțuri, SMS, chat și mesagerie de afaceri contribuie la un context guvernat unic al clientului și vehiculului. Clientul nu ar trebui să repete povestea la fiecare transfer, iar dealerul ar trebui să păstreze responsabilitatea, statutul consimțământului, acțiunea următoare și un istoric auditabil, fără a colecta mai multe date decât este necesar.

1. Multicanal versus omnicanal

Un dealer multicanal oferă mai multe moduri de a lua legătura. Un dealer omnicanal păstrează contextul atunci când clientul schimbă canalul. O solicitare web urmată de un apel telefonic nu ar trebui să creeze două lead-uri concurente. Un vânzător care răspunde din Outlook nu ar trebui să facă istoricul invizibil pentru consultantul de service. Un client care deschide o ofertă digitală nu ar trebui să fie nevoit să reafirme ce vehicul și ce mașină la schimb sunt discutate.

API-ul Sales Lead al STAR definește date comune despre client, vehicul și statutul lead-ului pentru schimbul între OEM-uri, dealeri, sisteme DMS și CRM.[1] Aceasta este o infrastructură utilă, dar continuitatea operațională necesită de asemenea potrivire, responsabilitate, permisiuni și adoptare de către utilizatori.

2. Construiți o hartă a canalelor înainte de integrare

Listați fiecare sursă și destinație: site-ul dealerului, formularul OEM, platforma de anunțuri, urmărirea apelurilor, telefonul sucursalei, e-mail, calendarul Outlook, SMS, WhatsApp Business, chat web, programarea la service și oferta digitală. Pentru fiecare, documentați identificatorul clientului, conținutul, marcajul temporal, informațiile de consimțământ, atașamentele, notificarea de eșec și echipa responsabilă.

Nu fiecare canal are nevoie de același răspuns sau de aceeași perioadă de păstrare. Confirmarea unei programări la service, promovarea vânzărilor, actualizarea garanției și o reclamație urmăresc scopuri diferite. O singură interfață de tip inbox nu ar trebui să șteargă aceste diferențe.

3. Rezolvați identitatea fără fuziuni riscante

Potrivirea poate folosi e-mailul, telefonul, ID-ul clientului, VIN-ul, numărul de înmatriculare, comanda sau contextul de service. Identificatorii exacți sunt utili, dar necesită totuși revizuire atunci când există conturi familiale partajate, flote de afaceri sau numere de telefon reciclate. Potrivirile probabilistice ar trebui să arate nivelul de încredere și sursa, iar utilizatorii ar trebui să poată separa o fuziune greșită fără a pierde istoricul.

Gestionarea duplicatelor afectează de asemenea raportarea performanței. Trei mesaje de la un client nu ar trebui să conteze automat ca trei oportunități unice. Păstrați evenimentele pe canal, raportând în același timp parcursul consolidat al clientului.

4. Păstrați comunicarea deținută de companie și sensibilă la roluri

Mesageria personală și căsuțele poștale private creează riscuri de continuitate și guvernanță atunci când angajații pleacă sau își schimbă rolurile. Canalele gestionate de companie pot păstra șabloanele, accesul și istoricul sub controlul dealerului. Acest lucru nu înseamnă că fiecare angajat ar trebui să vadă fiecare conversație. Rolul, sucursala, sensibilitatea reclamațiilor și contextul financiar pot necesita un acces mai restrâns.

Documentația publică a Keyloop enumeră specificațiile produselor CRM, de comunicații, post-vânzare și conexe, ilustrând faptul că fluxul de lucru omnicanal este o categorie a industriei, nu un concept exclusiv Omnetic.[2] Comparați produse exacte și module contractate, nu portofolii corporative.

5. Integrați confidențialitatea și consimțământul în istoric

GDPR necesită legalitate, limitarea scopului, minimizare, limitarea stocării, securitate și responsabilitate.[3] Orientările Comisiei Europene privind confidențialitatea din concepție subliniază garanțiile încă din primele etape de proiectare și limitarea prelucrării implicite la ceea ce este necesar.[4] O vizualizare completă a clientului trebuie, prin urmare, să distingă înregistrările operaționale, păstrarea legală, comunicarea de service și preferința de marketing.

Șabloanele ar trebui să reflecte limba și alegerea canalului clientului. Răspunsurile automate ar trebui să identifice dealerul și să ofere o cale de escaladare. Înregistrarea și transcrierea apelurilor necesită revizuirea jurisdicției și a scopului.

6. Măsurați atât experiența clientului, cât și controlul

7. Testați modurile de eșec

Ce se întâmplă când o integrare este căzută, un mesaj sosește fără număr de telefon, un client renunță, un angajat răspunde de pe un dispozitiv personal sau două sucursale revendică lead-ul? Sistemul are nevoie de cozi, alerte de excepție, reconciliere și recuperare. „Captare 100%” nu este o afirmație universală sigură fără canale și excepții definite.

Un acord de nivel de serviciu pentru canal ar trebui să definească mai mult decât timpul de funcționare. Documentați cât de repede sosesc de obicei evenimentele, cum este păstrată ordinea, cum sunt gestionate atașamentele, ce metadate pot lipsi și cât timp rămân disponibile mesajele eșuate pentru reîncercare. Când un furnizor își schimbă API-ul sau politica de șabloane, dealerul are nevoie de un responsabil pentru revizuirea impactului și comunicarea cu clienții.

Proiectarea conversației este un alt strat operațional. Șabloanele pot îmbunătăți consistența, dar nu ar trebui să transforme fiecare interacțiune în același script. Separați confirmarea tranzacțională, urmărirea solicitată, informațiile de siguranță de service și marketingul. Oferiți consultanților istoricul clientului și o acțiune următoare recomandată, permițându-le totodată să corecteze contextul. Traducerea și redactarea AI necesită revizuire acolo unde o dată, un preț sau o afirmație tehnică greșită ar putea crea un angajament al clientului.

Pentru implementare, începeți cu două canale care reprezintă un volum semnificativ și modele de eșec diferite, cum ar fi e-mailul de pe platformele de anunțuri și apelurile telefonice primite. Reconciliați numărul de surse, duplicatele, evenimentele de răspuns și rezultatele în raport cu procesul anterior. Adăugați mesageria doar după ce identitatea, consimțământul și responsabilitatea funcționează fiabil. Această secvențiere produce dovezi mai puternice decât lansarea simultană a fiecărui conector și descoperirea ulterioară că managementul nu poate distinge un mesaj lipsă de o eroare de potrivire.

Unde se potrivește Omnetic

Pagina publică CRM a Omnetic descrie captarea contactelor din surse diferite, gestionarea oportunităților, planificarea în vânzări și service, informațiile despre client într-un singur loc și istoricul interacțiunilor până la factură.[5] Aceasta este o bază credibilă pentru continuitatea comunicării în jurul unei înregistrări partajate a clientului. Conectorii exacți pentru telefon, e-mail, mesagerie, platforme de anunțuri și rețele sociale, împreună cu consimțământul, păstrarea, comportamentul în funcție de orele de funcționare și soluția de rezervă, ar trebui demonstrate pentru piața vizată. Orice afirmație privind răspunsul, conversia sau captarea completă necesită acoperire de canal definită și dovezi de cohortă aprobate.

Limitări și avertismente

Nicio platformă nu poate obliga un client să rămână pe canale integrate. API-urile, politicile de mesagerie și conținutul platformelor de anunțuri se schimbă. Potrivirea identității poate eșua. Un istoric unificat poate crește de asemenea expunerea privind confidențialitatea dacă permisiunile sunt largi. Guvernați integrarea canalelor, calitatea datelor, păstrarea și gestionarea incidentelor ca operațiuni continue.

Surse

1. STAR, Sales Lead API.
2. Keyloop, documentația produsului pentru Marea Britanie. Sursă de produs a furnizorului.
3. Uniunea Europeană, GDPR.
4. Comisia Europeană, protecția datelor începând cu momentul conceperii și în mod implicit.
5. Omnetic, CRM. Sursă de produs a furnizorului.