Klientu saziņa
Vairākkanālu tirgotāja saziņa: viena klienta laika līnija
Klienti pārvietojas starp tirdzniecības vietnes formām, tālruni, e-pastu, ziņojumapmaiņu un salonu. Tirgotāja kontekstam, atbildībai un privātuma kontrolēm jāpārvietojas kopā ar tiem.

Īsā atbilde
Vairākkanālu tirgotāja saziņa nozīmē, ka apstiprinātas tālruņa, e-pasta, tīmekļa, tirdzniecības vietnes, SMS, tērzēšanas un biznesa ziņojumapmaiņas mijiedarbības veido vienu pārvaldītu klienta un transportlīdzekļa kontekstu. Klientam nav jāatkārto stāsts katrā nodošanā, un autosalonam jāsaglabā atbildība, piekrišanas statuss, nākamā darbība un audititējama vēsture, nevācot vairāk datu nekā nepieciešams.
1. Vairāki kanāli pretstatā vairākkanālu pieejai
Tirgotājs ar vairākiem kanāliem piedāvā vairākus veidus, kā sazināties. Vairākkanālu tirgotājs saglabā kontekstu, kad klients maina kanālu. Tīmekļa pieprasījumam, kam seko zvans, nav jārada divi konkurējoši potenciālie klienti. Pārdevēja atbildei no Outlook nav jāpadara vēsture neredzama servisa konsultantam. Klientam, kas atver digitālu piedāvājumu, nav jāatkārto, kurš transportlīdzeklis un ieskaitāmais auto tiek apspriests.
STAR Sales Lead API definē kopīgus klienta, transportlīdzekļa un potenciālā klienta statusa datus apmaiņai starp OEM, tirgotājiem, DMS un CRM sistēmām.[1] Tā ir noderīga infrastruktūra, taču darbības nepārtrauktībai nepieciešama arī sasaiste, atbildība, atļaujas un lietotāju pieņemšana.
2. Izveidojiet kanālu karti pirms integrācijas
Uzskaitiet katru avotu un galamērķi: tirgotāja tīmekļa vietni, OEM formu, sludinājumu vietni, zvanu izsekošanu, filiāles tālruni, e-pastu, Outlook kalendāru, SMS, WhatsApp Business, tīmekļa tērzēšanu, servisa rezervāciju un digitālo piedāvājumu. Katram dokumentējiet klienta identifikatoru, saturu, laika zīmogu, piekrišanas informāciju, pielikumus, kļūmes paziņojumu un atbildīgo komandu.
Ne katram kanālam nepieciešama vienāda atbilde vai saglabāšana. Servisa rezervācijas apstiprinājumam, pārdošanas akcijai, garantijas atjauninājumam un sūdzībai ir dažādi mērķi. Vienotai iesūtnes saskarnei nav jāizdzēš šīs atšķirības.
3. Noskaidrojiet identitāti bez nedrošas apvienošanas
Sasaistei var izmantot e-pastu, tālruni, klienta ID, VIN, reģistrācijas numuru, pasūtījuma vai servisa kontekstu. Precīzi identifikatori ir noderīgi, taču joprojām jāpārskata, kad pastāv kopīgi ģimenes konti, biznesa autoparki vai atkārtoti izmantoti tālruņu numuri. Varbūtiskām sasaistēm jārāda pārliecība un avots, un lietotājiem jāvar atdalīt kļūdainu apvienošanu, nezaudējot vēsturi.
Dublikātu pārvaldība ietekmē arī snieguma pārskatus. Trīs ziņojumi no viena klienta nedrīkst automātiski tikt skaitīti kā trīs unikālas iespējas. Saglabājiet kanālu notikumus, vienlaikus ziņojot par apvienoto klienta ceļu.
4. Saglabājiet saziņu uzņēmuma īpašumā un lomām atbilstošu
Personiskā ziņojumapmaiņa un privātas pastkastes rada nepārtrauktības un pārvaldības riskus, kad darbinieki aiziet vai maina lomas. Biznesa pārvaldīti kanāli var uzturēt veidnes, piekļuvi un vēsturi autosalona kontrolē. Tas nenozīmē, ka katram darbiniekam jāredz katra saruna. Loma, filiāle, sūdzības jutība un finanšu konteksts var pieprasīt šaurāku piekļuvi.
Keyloop publiskā dokumentācija uzskaita CRM, saziņas, popārdošanas un saistītu produktu specifikācijas, parādot, ka vairākkanālu darba plūsma ir nozares kategorija, nevis tikai Omnetic koncepts.[2] Salīdziniet precīzus produktus un līgumā noteiktos moduļus, nevis korporatīvos portfeļus.
5. Iestrādājiet privātumu un piekrišanu laika līnijā
BDAR pieprasa likumību, mērķa ierobežojumu, minimizāciju, glabāšanas ierobežojumu, drošību un pārskatatbildību.[3] Eiropas Komisijas integrētas privātuma aizsardzības vadlīnijas uzsver aizsardzības pasākumus no agrākā projektēšanas posma un noklusējuma apstrādes ierobežošanu līdz nepieciešamajam.[4] Tāpēc pilnīgam klienta skatam jānošķir darbības ieraksti, juridiskā saglabāšana, servisa saziņa un mārketinga izvēle.
Veidnēm jāatspoguļo klienta valoda un kanāla izvēle. Automatizētām atbildēm jāidentificē autosalons un jānodrošina eskalācijas ceļš. Zvanu ierakstīšanai un transkribēšanai nepieciešama jurisdikcijas un mērķa pārskatīšana.
6. Mēriet gan klienta pieredzi, gan kontroli
| Joma | Rādītājs | Kāpēc tas ir svarīgi | Atruna |
|---|---|---|---|
| Fiksēšana | Ienestie derīgie ziņojumi | Parāda kanāla uzticamību | Definējiet izņēmumus un pārtraukumus |
| Identitāte | Dublikātu un apvienošanas līmenis | Aizsargā klienta nepārtrauktību | Pārskatiet kļūdainas apvienošanas |
| Atbilde | Laiks līdz jēgpilnai atbildei | Pārbauda atbildību un personālu | Neskaitiet tikai saņemšanu |
| Nodošana | Pārpiešķiršanas un atkārtotas atvēršanas līmenis | Atrod bojātu novirzīšanu | Daži pārsūtījumi ir pamatoti |
| Piekrišana | Kanāla/mērķa pārklājums | Atbalsta atbilstošu saziņu | Tiesiskais pamats atšķiras |
| Rezultāts | Iespēja, rezervācija vai slēgšana | Saista saziņu ar darbu | Izvairieties no vienkāršotas attiecinājuma |
7. Testējiet kļūmju veidus
Kas notiek, kad integrācija nedarbojas, ziņojums pienāk bez tālruņa numura, klients atsakās, darbinieks atbild no personīgas ierīces vai divas filiāles pretendē uz potenciālo klientu? Sistēmai nepieciešamas rindas, izņēmumu brīdinājumi, saskaņošana un atgūšana. „100% fiksēšana” nav drošs universāls apgalvojums bez definētiem kanāliem un izņēmumiem.
Kanāla pakalpojuma līmeņa vienošanās jādefinē vairāk nekā tikai pieejamības laiks. Dokumentējiet, cik ātri parasti pienāk notikumi, kā tiek saglabāta secība, kā tiek apstrādāti pielikumi, kādi metadati var trūkt un cik ilgi neizdevušies ziņojumi paliek pieejami atkārtotam mēģinājumam. Kad piegādātājs maina savu API vai veidņu politiku, tirgotājam nepieciešams atbildīgais ietekmes pārskatīšanai un saziņai ar klientiem.
Sarunas projektēšana ir vēl viens darbības slānis. Veidnes var uzlabot konsekvenci, taču tām nevajadzētu padarīt katru mijiedarbību par to pašu skriptu. Nošķiriet darījuma apstiprinājumu, pieprasītu turpinājumu, servisa drošības informāciju un mārketingu. Nodrošiniet konsultantiem klienta vēsturi un ieteicamo nākamo darbību, ļaujot viņiem labot kontekstu. Tulkošana un MI melnrakstu izveide jāpārskata tur, kur nepareizs datums, cena vai tehnisks apgalvojums varētu radīt klienta saistību.
Ieviešanai sāciet ar diviem kanāliem, kas pārstāv nozīmīgu apjomu un atšķirīgus kļūmju modeļus, piemēram, sludinājumu e-pastu un ienākošos zvanus. Saskaņojiet avotu skaitu, dublikātus, atbildes notikumus un rezultātus ar iepriekšējo procesu. Pievienojiet ziņojumapmaiņu tikai pēc tam, kad identitāte, piekrišana un atbildība darbojas uzticami. Šāda secība sniedz spēcīgākus pierādījumus nekā visu savienotāju vienlaicīga palaišana un vēlāka atklāšana, ka vadība nevar atšķirt trūkstošu ziņojumu no sasaistes kļūdas.
Kur iederas Omnetic
Omnetic publiskā CRM lapa apraksta kontaktu fiksēšanu no dažādiem avotiem, iespēju pārvaldību, plānošanu pārdošanā un servisā, klienta informāciju vienuviet un mijiedarbības vēsturi līdz pat rēķinam.[5] Tas ir ticams pamats saziņas nepārtrauktībai ap kopīgu klienta ierakstu. Precīzi tālruņa, e-pasta, ziņojumapmaiņas, tirdzniecības vietnes un sociālo mediju savienotāji, kopā ar piekrišanu, saglabāšanu, darba laika uzvedību un rezerves risinājumu, jāpierāda paredzētajam tirgum. Jebkuram apgalvojumam par atbildi, konversiju vai pilnīgu fiksēšanu nepieciešams definēts kanālu pārklājums un apstiprināti kohortas pierādījumi.
Ierobežojumi un atrunas
Neviena platforma nevar piespiest klientu palikt integrētajos kanālos. API, ziņojumapmaiņas politikas un tirdzniecības vietņu saturs mainās. Identitātes sasaiste var neizdoties. Vienota laika līnija var arī palielināt privātuma risku, ja atļaujas ir plašas. Pārvaldiet kanālu pievienošanu, datu kvalitāti, saglabāšanu un incidentu apstrādi kā notiekošu darbību.
Biežāk uzdotie jautājumi
Klienta konteksts, atbildība un nākamā darbība turpinās, klientam pārvietojoties starp apstiprinātiem kanāliem.
Nē. Vairāki kanāli sniedz izvēles; vairākkanālu pieeja savieno identitāti, vēsturi un darba plūsmu.
Tirgotājam piederoši biznesa kanāli ir drošāki nepārtrauktībai, piekļuvei, saglabāšanai un audititējamībai.
Pārklājums ir atkarīgs no integrācijām, atļaujām, pārtraukumiem, darbinieku uzvedības un klientu kanālu izvēles.
Avoti
- STAR, Sales Lead API.
- Keyloop, AK produkta dokumentācija. Piegādātāja produkta avots.
- Eiropas Savienība, BDAR.
- Eiropas Komisija, integrēta un pēc noklusējuma datu aizsardzība.
- Omnetic, CRM. Piegādātāja produkta avots.