Visų kanalų atstovo komunikacija: viena kliento laiko juosta

Trumpas atsakymas

Visų kanalų atstovo komunikacija reiškia, kad patvirtinti telefono, el. pašto, interneto, prekyvietės, SMS, pokalbių ir verslo žinučių ryšiai prisideda prie vieno valdomo kliento ir transporto priemonės konteksto. Klientui neturėtų reikėti kartoti istorijos kiekvieno perdavimo metu, o atstovybė turi išlaikyti atsakomybę, sutikimo statusą, kitą veiksmą ir audituojamą istoriją, nerinkdama daugiau duomenų nei būtina.

1. Keli kanalai ir visi kanalai

Kelių kanalų atstovas siūlo keletą būdų susisiekti. Visų kanalų atstovas išsaugo kontekstą, kai klientas pakeičia kanalą. Interneto užklausa, po kurios seka skambutis, neturėtų sukurti dviejų konkuruojančių potencialių klientų. Pardavėjo atsakymas iš „Outlook“ neturėtų paslėpti istorijos serviso konsultantui. Klientui, atidarančiam skaitmeninį pasiūlymą, neturėtų reikėti iš naujo nurodyti, kuri transporto priemonė ir įskaitomas automobilis aptariami.

STAR „Sales Lead“ API apibrėžia bendrus kliento, transporto priemonės ir potencialaus kliento būsenos duomenis mainams tarp OEM, atstovų, DMS ir CRM sistemų.[1] Tai naudinga infrastruktūra, tačiau veiklos tęstinumui taip pat reikia suderinimo, atsakomybės, teisių ir naudotojų priėmimo.

2. Prieš integraciją sudarykite kanalų žemėlapį

Išvardykite kiekvieną šaltinį ir paskirties vietą: atstovo svetainę, OEM formą, skelbimų prekyvietę, skambučių stebėjimą, padalinio telefoną, el. paštą, „Outlook“ kalendorių, SMS, „WhatsApp Business“, interneto pokalbius, serviso rezervaciją ir skaitmeninį pasiūlymą. Kiekvienam dokumentuokite kliento identifikatorių, duomenų turinį, laiko žymą, sutikimo informaciją, priedus, pranešimą apie gedimą ir atsakingą komandą.

Ne kiekvienam kanalui reikia to paties atsakymo ar saugojimo trukmės. Serviso rezervacijos patvirtinimas, pardavimo akcija, garantijos atnaujinimas ir skundas atitinka skirtingus tikslus. Viena bendra pašto dėžutės sąsaja neturėtų panaikinti šių skirtumų.

3. Nustatykite tapatybę be nesaugaus sujungimo

Suderinimui galima naudoti el. paštą, telefoną, kliento ID, VIN, registracijos numerį, užsakymo ar serviso kontekstą. Tikslūs identifikatoriai naudingi, tačiau juos vis tiek reikia peržiūrėti, kai egzistuoja bendros šeimos paskyros, verslo automobilių parkai ar pakartotinai naudojami telefono numeriai. Tikimybiniai atitikmenys turi rodyti patikimumą ir šaltinį, o naudotojai turi galėti atskirti klaidingą sujungimą neprarasdami istorijos.

Dublikatų valdymas taip pat veikia veiklos ataskaitas. Trys žinutės nuo vieno kliento neturėtų būti automatiškai skaičiuojamos kaip trys unikalios galimybės. Išsaugokite kanalų įvykius, kartu pateikdami suvestinį kliento kelią.

4. Palaikykite įmonei priklausančią ir vaidmenimis pagrįstą komunikaciją

Asmeninės žinutės ir privačios pašto dėžutės kelia tęstinumo ir valdymo riziką, kai darbuotojai išeina ar keičia vaidmenis. Verslo valdomi kanalai gali išlaikyti šablonus, prieigą ir istoriją atstovybės kontrolėje. Tai nereiškia, kad kiekvienas darbuotojas turėtų matyti kiekvieną pokalbį. Vaidmuo, padalinys, skundo jautrumas ir finansinis kontekstas gali reikalauti siauresnės prieigos.

„Keyloop“ vieša dokumentacija nurodo CRM, komunikacijos, popardavimo ir susijusių produktų specifikacijas, tai parodo, kad visų kanalų darbo eiga yra pramonės kategorija, o ne vien „Omnetic“ sąvoka.[2] Lyginkite konkrečius produktus ir sutartus modulius, o ne įmonių portfelius.

5. Į laiko juostą įtraukite privatumą ir sutikimą jau projektavimo etape

BDAR reikalauja teisėtumo, tikslo apribojimo, duomenų kiekio mažinimo, saugojimo trukmės ribojimo, saugumo ir atskaitomybės.[3] Europos Komisijos gairės dėl privatumo pagal dizainą pabrėžia apsaugos priemones nuo pat ankstyviausio projektavimo etapo ir numatytojo duomenų tvarkymo ribojimą iki būtino.[4] Todėl išsamus kliento vaizdas turi atskirti veiklos įrašus, teisinį saugojimą, serviso komunikaciją ir rinkodaros pageidavimus.

Šablonai turi atspindėti kliento kalbą ir pasirinktą kanalą. Automatiniai atsakymai turi identifikuoti atstovybę ir suteikti eskalavimo kelią. Skambučių įrašymui ir transkribavimui reikia peržiūrėti jurisdikciją ir tikslą.

6. Matuokite ir kliento patirtį, ir kontrolę

7. Išbandykite gedimo scenarijus

Kas nutinka, kai integracija neveikia, žinutė ateina be telefono numerio, klientas atsisako sutikimo, darbuotojas atsako iš asmeninio įrenginio arba du padaliniai pretenduoja į tą patį potencialų klientą? Sistemai reikia eilių, įspėjimų apie išimtis, sulyginimo ir atkūrimo. „100 % fiksavimas“ nėra saugus universalus teiginys be apibrėžtų kanalų ir išimčių.

Kanalo paslaugų lygio sutartis turi apibrėžti daugiau nei veikimo laiką. Dokumentuokite, kaip greitai paprastai atkeliauja įvykiai, kaip išsaugoma tvarka, kaip tvarkomi priedai, kokių metaduomenų gali trūkti ir kiek laiko nepavykusios žinutės lieka pasiekiamos pakartotiniam bandymui. Kai teikėjas pakeičia savo API ar šablonų politiką, atstovui reikia atsakingo asmens poveikio peržiūrai ir komunikacijai su klientais.

Pokalbių projektavimas yra dar vienas veiklos lygmuo. Šablonai gali pagerinti nuoseklumą, tačiau jie neturėtų paversti kiekvienos sąveikos tuo pačiu scenarijumi. Atskirkite sandorio patvirtinimą, prašomą tolesnį kontaktą, serviso saugumo informaciją ir rinkodarą. Konsultantams suteikite kliento istoriją ir rekomenduojamą kitą veiksmą, kartu leisdami ištaisyti kontekstą. Vertimą ir DI rengiamus juodraščius reikia peržiūrėti tais atvejais, kai neteisinga data, kaina ar techninis teiginys galėtų sukurti kliento įsipareigojimą.

Diegimui pradėkite nuo dviejų kanalų, kurie atspindi reikšmingą apimtį ir skirtingus gedimo modelius, pavyzdžiui, skelbimų el. paštą ir įeinančius skambučius. Sulyginkite šaltinių skaičių, dublikatus, atsakymo įvykius ir rezultatus su ankstesniu procesu. Žinutes pridėkite tik tada, kai tapatybė, sutikimas ir atsakomybė patikimai veikia. Toks nuoseklumas suteikia stipresnius įrodymus nei visų jungčių paleidimas vienu metu ir vėlesnis atradimas, kad vadovybė negali atskirti trūkstamos žinutės nuo suderinimo klaidos.

Kur tinka „Omnetic“

Viešame „Omnetic“ CRM puslapyje aprašomas kontaktų fiksavimas iš skirtingų šaltinių, galimybių valdymas, planavimas pardavimo ir serviso srityse, kliento informacija vienoje vietoje ir sąveikų istorija iki pat sąskaitos.[5] Tai patikimas pagrindas komunikacijos tęstinumui aplink bendrą kliento įrašą. Konkretūs telefono, el. pašto, žinučių, prekyvietės ir socialinių tinklų jungikliai, kartu su sutikimu, saugojimo trukme, darbo valandų elgsena ir atsargine schema, turėtų būti pademonstruoti numatytai rinkai. Bet koks teiginys apie atsakymą, konversiją ar pilną fiksavimą reikalauja apibrėžtos kanalų aprėpties ir patvirtintų kohortos įrodymų.

Ribotumai ir išlygos

Jokia platforma negali priversti kliento likti integruotuose kanaluose. API, žinučių politika ir prekyvietės duomenų formatai keičiasi. Tapatybės suderinimas gali nepavykti. Vieninga laiko juosta taip pat gali padidinti privatumo riziką, jei teisės yra per plačios. Kanalų prijungimą, duomenų kokybę, saugojimo trukmę ir incidentų tvarkymą valdykite kaip nuolatinę veiklą.

Šaltiniai

1. STAR, Sales Lead API.
2. „Keyloop“, JK produkto dokumentacija. Tiekėjo produkto šaltinis.
3. Europos Sąjunga, BDAR.
4. Europos Komisija, duomenų apsauga projektuojant ir pagal numatytuosius nustatymus.
5. Omnetic, CRM. Tiekėjo produkto šaltinis.