Komunikacija s strankami
Večkanalna komunikacija prodajalca: ena časovnica stranke
Stranke se premikajo med obrazci tržnic, telefonom, e-pošto, sporočanjem in razstavnim salonom. Kontekst, lastništvo in kontrole zasebnosti prodajalca naj se premikajo z njimi.

Kratek odgovor
Večkanalna komunikacija prodajalca pomeni, da odobrene interakcije prek telefona, e-pošte, spleta, tržnice, SMS, klepeta in poslovnega sporočanja prispevajo k enemu upravljanemu kontekstu stranke in vozila. Stranki ni treba ponoviti zgodbe ob vsaki predaji, prodajalec pa naj ohrani lastništvo, status soglasja, naslednji ukrep in revizijsko sledljivo zgodovino, ne da bi zbiral več podatkov, kot je potrebno.
1. Večkanalnost proti pravi večkanalni izkušnji
Prodajalec z več kanali ponuja več načinov za stik. Prodajalec s pravo večkanalno izkušnjo ohrani kontekst, ko stranka zamenja kanal. Spletno povpraševanje, ki mu sledi klic, ne bi smelo ustvariti dveh konkurenčnih povpraševanj. Prodajalec, ki odgovori iz Outlooka, ne bi smel narediti zgodovine nevidne za servisnega svetovalca. Stranki, ki odpre digitalno ponudbo, ni treba ponovno navesti, katero vozilo in zamenjava sta predmet pogovora.
Sales Lead API organizacije STAR opredeljuje skupne podatke o stranki, vozilu in statusu povpraševanja za izmenjavo med proizvajalci vozil, prodajalci, DMS in CRM sistemi.[1] To je koristna infrastruktura, vendar operativna neprekinjenost zahteva tudi ujemanje, lastništvo, dovoljenja in sprejetje pri uporabnikih.
2. Pred integracijo izdelajte zemljevid kanalov
Naštejte vsak vir in cilj: spletna stran prodajalca, obrazec proizvajalca vozil, oglasna tržnica, sledenje klicem, telefon poslovalnice, e-pošta, koledar Outlook, SMS, WhatsApp Business, spletni klepet, rezervacija servisa in digitalna ponudba. Za vsakega dokumentirajte identifikator stranke, vsebino, časovni žig, informacije o soglasju, priloge, obvestilo o napaki in odgovorno ekipo.
Ne potrebuje vsak kanal istega odziva ali hrambe. Potrditev rezervacije servisa, prodajna promocija, posodobitev garancije in reklamacija sledijo različnim namenom. Vmesnik z enim predalom naj teh razlik ne izbriše.
3. Razrešite identiteto brez tveganega združevanja
Ujemanje lahko uporablja e-pošto, telefon, ID stranke, VIN, registracijo, naročilo ali servisni kontekst. Natančni identifikatorji so koristni, a še vedno potrebujejo pregled, kadar obstajajo skupni družinski računi, poslovni vozni parki ali ponovno uporabljene telefonske številke. Verjetnostna ujemanja naj pokažejo zanesljivost in vir, uporabniki pa naj lahko razdružijo napačno združitev brez izgube zgodovine.
Upravljanje podvojenih zapisov vpliva tudi na poročanje o uspešnosti. Tri sporočila ene stranke se ne bi smela samodejno šteti kot tri edinstvene priložnosti. Ohranite dogodke kanalov, medtem ko poročate o konsolidirani poti stranke.
4. Ohranite komunikacijo v lasti podjetja in glede na vlogo
Osebno sporočanje in zasebni poštni predali ustvarjajo tveganja za neprekinjenost in upravljanje, ko zaposleni odidejo ali zamenjajo vlogo. Poslovno upravljani kanali lahko ohranijo predloge, dostop in zgodovino pod nadzorom prodajalca. To ne pomeni, da naj vsak zaposleni vidi vsak pogovor. Vloga, poslovalnica, občutljivost reklamacije in finančni kontekst lahko zahtevajo ožji dostop.
Javna dokumentacija podjetja Keyloop navaja specifikacije izdelkov za CRM, komunikacijo, poprodajne storitve in sorodne funkcije, kar ponazarja, da je večkanalen delovni proces panožna kategorija, ne koncept, ki bi bil značilen le za Omnetic.[2] Primerjajte natančne izdelke in pogodbene module, ne korporativnih portfeljev.
5. Vgradite zasebnost in soglasje v časovnico
GDPR zahteva zakonitost, omejitev namena, minimizacijo, omejitev shranjevanja, varnost in odgovornost.[3] Smernice Evropske komisije o vgrajeni zasebnosti poudarjajo zaščitne ukrepe že od najzgodnejše faze zasnove in omejitev privzete obdelave na to, kar je potrebno.[4] Popoln pogled na stranko mora zato razlikovati operativne zapise, zakonsko hrambo, servisno komunikacijo in tržne preference.
Predloge naj odražajo jezik in izbiro kanala stranke. Samodejni odgovori naj identificirajo prodajalca in ponudijo pot eskalacije. Snemanje in prepis klicev zahtevata pregled pristojnosti in namena.
6. Merite tako izkušnjo stranke kot nadzor
| Področje | Metrika | Zakaj je pomembno | Pridržek |
|---|---|---|---|
| Zajem | Zajeta veljavna sporočila | Pokaže zanesljivost kanala | Opredelite izjeme in izpade |
| Identiteta | Stopnja podvajanja in združevanja | Ščiti neprekinjenost stranke | Preglejte napačne združitve |
| Odziv | Čas do smiselnega odziva | Preverja lastništvo in zasedbo osebja | Ne štejte le prejema |
| Predaja | Stopnja ponovne dodelitve in ponovnega odpiranja | Odkrije pokvarjeno usmerjanje | Nekateri prenosi so veljavni |
| Soglasje | Pokritost kanala/namena | Podpira skladno komunikacijo | Zakonita podlaga se razlikuje |
| Izid | Priložnost, rezervacija ali zaključek | Povezuje komunikacijo z delom | Izogibajte se poenostavljenemu pripisu |
7. Preizkusite načine odpovedi
Kaj se zgodi, ko integracija odpove, sporočilo prispe brez telefonske številke, stranka se odjavi, zaposleni odgovori z osebne naprave ali dve poslovalnici zahtevata isto povpraševanje? Sistem potrebuje čakalne vrste, opozorila o izjemah, usklajevanje in okrevanje. »100-odstoten zajem« brez opredeljenih kanalov in izjem ni varna univerzalna trditev.
Sporazum o ravni storitve za kanal naj določi več kot le razpoložljivost. Dokumentirajte, kako hitro dogodki običajno prispejo, kako se ohranja vrstni red, kako se obravnavajo priloge, kateri metapodatki lahko manjkajo in kako dolgo neuspela sporočila ostanejo na voljo za ponovni poskus. Ko ponudnik spremeni svoj API ali politiko predlog, prodajalec potrebuje lastnika za pregled vpliva in komunikacijo s strankami.
Zasnova pogovora je še ena operativna plast. Predloge lahko izboljšajo doslednost, vendar naj ne spremenijo vsake interakcije v isti scenarij. Ločite transakcijsko potrditev, zahtevano nadaljnjo komunikacijo, servisne varnostne informacije in trženje. Svetovalcem zagotovite zgodovino strank in priporočen naslednji ukrep, hkrati pa jim omogočite popravek konteksta. Prevod in osnutki UI potrebujejo pregled, kjer bi napačen datum, cena ali tehnična izjava lahko ustvarila zavezo stranki.
Za uvedbo začnite z dvema kanaloma, ki predstavljata smiseln obseg in različne vzorce odpovedi, na primer e-pošto z oglasa in dohodne klice. Uskladite števila virov, podvojene zapise, dogodke odziva in izide s prejšnjim procesom. Sporočanje dodajte šele, ko identiteta, soglasje in lastništvo zanesljivo delujejo. Tako zaporedje ustvari močnejše dokaze kot hkraten zagon vseh konektorjev in poznejše odkritje, da vodstvo ne more razlikovati manjkajočega sporočila od napake ujemanja.
Kje se uvršča Omnetic
Javna stran CRM Omnetica opisuje zajem stikov iz različnih virov, upravljanje priložnosti, načrtovanje v prodaji in servisu, informacije o stranki na enem mestu in zgodovino interakcij vse do računa.[5] To je verodostojna osnova za neprekinjenost komunikacije okoli skupnega zapisa stranke. Natančne konektorje za telefon, e-pošto, sporočanje, tržnico in družbena omrežja, skupaj s soglasjem, hrambo, vedenjem glede poslovnega časa in nadomestno rešitvijo, je treba dokazati za predvideni trg. Vsaka trditev o odzivu, konverziji ali popolnem zajemu zahteva opredeljeno pokritost kanalov in odobrene dokaze kohorte.
Omejitve in pridržki
Nobena platforma ne more prisiliti stranke, da ostane na integriranih kanalih. API-ji, politike sporočanja in vsebine tržnic se spreminjajo. Ujemanje identitete lahko odpove. Enotna časovnica lahko tudi poveča izpostavljenost zasebnosti, če so dovoljenja široka. Upravljajte uvajanje kanalov, kakovost podatkov, hrambo in obravnavo incidentov kot stalno poslovanje.
Pogosta vprašanja
Kontekst stranke, lastništvo in naslednji ukrep se nadaljujejo, ko se stranka premika med odobrenimi kanali.
Ne. Večkanalnost ponuja možnosti; prava večkanalna izkušnja poveže identiteto, zgodovino in delovni proces.
Poslovni kanali v lasti prodajalca so varnejši za neprekinjenost, dostop, hrambo in revizijsko sledljivost.
Pokritost je odvisna od integracij, dovoljenj, izpadov, vedenja zaposlenih in izbire kanala stranke.
Viri
- STAR, Sales Lead API.
- Keyloop, dokumentacija izdelka za Veliko Britanijo. Vir podatkov ponudnika izdelka.
- Evropska unija, GDPR.
- Evropska komisija, vgrajeno in privzeto varstvo podatkov.
- Omnetic, CRM. Vir podatkov ponudnika izdelka.