Najhitreje naredite podporno sporočilo bolj ustrezno tako, da ga nehate pisati na slepo. Če sporočilo že ve, kaj je kupec kupil, kdaj je bilo odposlano, kje je in ali je že prej imel težave, izgine polovica preigravanja sem in tja. “Hvala, ker ste nas kontaktirali, prosimo, navedite številko naročila” postane “Vaše naročilo #4821 je bilo odposlano v torek in prispe v petek — tukaj je sledenje.” Ista avtomatizacija, divje drugačna izkušnja in en odgovor manj, ki ga mora kupec poslati. Tu gre za praktično napeljavo: katera polja o naročilu potegniti, v katera sporočila in kako narediti, da vsako pristane kot konkretno, ne splošno.

Zakaj splošna sporočila sploh ustvarjajo podporne zahtevke, je sorodno, a ločeno vprašanje, ki ga obravnavam samo zase v zakaj kupci kontaktirajo podporo, ko so avtomatizirani emaili preveč splošni. Tukaj predpostavljamo, da ste se odločili to popraviti in želite vedeti točno, katere podatke uporabiti.

Težava: vaša podporna sporočila o kupcu ne vedo nič

Večina avtomatiziranih podpornih in ponakupnih sporočil je napisanih enkrat, za vse. Ne morejo biti konkretna, ker nimajo dostopa do ničesar konkretnega. Zato se izmikajo. “Vaše naročilo je na poti.” Katero naročilo? “Če imate kakršne koli težave z izdelkom, nam sporočite.” S katerim izdelkom?

Kupec to prebere in mu ne odgovori na nič, kar je res želel vedeti. Prišel je z resničnim vprašanjem — kje je moja stvar, kako to uporabljam, ali prihaja nadomestek — in dobil predlogo. Zato odgovori ali odpre zahtevek ali oboje. Sporočilo, ki naj bi zmanjšalo stike, jih je ravno ustvarilo, ker je pustilo konkretno vprašanje viseti.

Zakaj “dodaj oznako z imenom” ni rešitev

Običajen poskus ustreznosti so oznake za personalizacijo: vstavite {{first_name}} in temu rečete personalizirano. “Živjo Sara, vaše naročilo je na poti.” Sarino ime ni informacija, ki jo je potrebovala. Še vedno ne ve, katero naročilo, kaj je v njem ali kdaj pristane.

Prava ustreznost v podpornem kontekstu izhaja iz podatkov o naročilu in vedenju, ne iz podatkov o identiteti. Ime je okras. Številka naročila, izdelek, datum odpošiljanja, status dostave, rok za vračilo, oznaka pretekle težave — to je bistvo. Sporočilo, ki pove pravo dejstvo brez imena, prekaša toplo pozdravljeno sporočilo, ki ne pove nič uporabnega. Mešanje teh dveh je razlog, da toliko “personaliziranih” tokov še vedno poganja obseg podpore.

Kje je izguba: ponovljena kroženja, ki bi jih polje s podatki zaprlo

Vsako splošno podporno sporočilo, ki prisili k nadaljevanju, je kroženje, ki ste ga plačali dvakrat. Kupec porabi trud za ponovno razlaganje; vaša ekipa porabi čas za spraševanje in iskanje tega, kar je sistem že vedel.

Naredite izračun na enem pogostem primeru. Vprašanje “kje je moje naročilo”, ki prispe brez konteksta, vzame predstavniku podpore, recimo, štiri minute: prebere, vpraša za številko naročila, čaka, poišče, odgovori. Isto vprašanje, če bi vaša e-pošta z obvestilom o dostavi že takoj pokazala sledenje, pogosto sploh ni poslano. Če na mesec obravnavate 300 stikov o statusu naročila in boljši podatki preprečijo celo tretjino teh, je to 100 zahtevkov na mesec manj — recimo šest ali sedem ur podpornega časa nazaj, vsak mesec. (Ilustrativno — izmerite lasten preplet zahtevkov.) Priročnik za ta konkreten primer je v kako z boljšo avtomatizacijo zmanjšati vprašanja “kje je moje naročilo”.

Kateri podatki o naročilu dejansko naredijo sporočilo ustrezno

Vsi podatki si ne zaslužijo svojega mesta. To so polja, ki zanesljivo ubijejo nadaljevanje, približno po vrstnem redu vrednosti:

• Številka naročila in postavke. Kaj so kupili, poimenovano. Omogoča vam, da govorite o “vaši orehovi klubski mizici”, ne o “vašem naročilu”.
• Status izpolnitve in sledenja. Odposlano ali ne, prevoznik, povezava za sledenje, trenutna lokacija. To eno polje samo po sebi prepreči večino vprašanj o statusu.
• Predviden datum dostave. Konkreten datum vsakič prekaša “kmalu”. Meglen čas je prvi razlog, da ljudje preganjajo naročilo.
• Potrditev dostave. Ali je dejansko prispelo, spremeni celotno sporočilo — “kako gre?” nekomu, ki ima škatlo, proti “še vedno na poti” nekomu, ki je nima.
• Rok za vračilo/menjavo. Vedeti, da so na 3. dnevu od 30 proti 45. dnevu, spremeni, kaj lahko ponudite in kaj bi morali reči.
• Oznaka pretekle težave. Je ta kupec že prej imel pritožbo? Ponovljena težava potrebuje drugačen, bolj skrben ton.

Te potegnite v sporočila, kjer so pomembna: obvestila o dostavi, obvestila o zamujenih naročilih, ponakupne preverbe in odgovore, ki jih pošlje vaša podpora. Vsako polje spremeni izmikanje v dejstvo.

Kaj avtomatizirati in kako podatki to poganjajo

Cilj so sporočila, ki se razvejajo glede na resnično stanje naročila, namesto da vsem pošiljajo eno ploščato predlogo.

• Sprožite ob dogodku naročila, ne ob koledarju. Obvestilo o dostavi se sproži, ko prevoznik skenira paket, in s seboj nese podatke o sledenju. Nadaljevanje po dostavi se sproži ob potrditvi dostave, ne “7 dni po nakupu” — to je razlika med prispetjem, ko prispe škatla, in prispetjem, ko je še na poti. Več o tem v kako s potrditvijo dostave sprožiti pravo nadaljevanje.
• Razvejite glede na status dostave. Če je dostavljeno, pošljite pomoč pri uporabi. Če zamuja čez oceno, pošljite proaktivno “zamuja, tukaj je, kje je”, preden morajo vprašati.
• Razvejite glede na izdelek. Sporočilo o izdelku, ki potrebuje nastavitev, naj poveže vodnik za nastavitev; potrošni material naj namigne, kdaj naročiti znova. En tok, različna vsebina glede na vrsto artikla.
• Segmentirajte glede na pretekle težave. Kupci, označeni s preteklo pritožbo, dobijo mehkejšo, bolj pozorno različico vsakega sporočila, povezanega s podporo.
• Cilj: konkretno sporočilo odgovori na konkretno vprašanje, preden ga mora kupec postaviti. Vsak zahtevek, ki se nikoli ne odpre, je zmaga.

Primer trgovine

Trgovina, ki prodaja espresso aparate, dobi veliko zahtevkov “je pokvarjen ali delam narobe” v prvem tednu. Prezgradijo ponakupni tok, da uporablja podatke o naročilu. Sporočilo se ne sproži na časovnik — čaka na potrditev dostave, nato pa, ker pozna točen naročeni model, pošlje vodnik za nastavitev in prvo pripravo za ta aparat, ne splošnega “hvala za nakup”. Kupec, ki je kupil osnovni model, dobi korake za odstranjevanje vodnega kamna za osnovni model; kupec, ki je kupil dvokotlovnik, dobi korake zanj. Vprašanja o statusu naročila in zahtevki “kako to uporabljam” oba upadeta, ker je vsako sporočilo že nagovorilo dejansko škatlo tega kupca. (Ilustrativen primer — prilagodite svojemu katalogu.)

Kako to meriti

• Stopnja nadaljevanja na sporočilo — kako pogosto dano avtomatizirano sporočilo sproži odgovor s prošnjo za več. Padajoče številke pomenijo, da podatki opravljajo svoje delo.
• Obseg zahtevkov o statusu naročila in uporabi — dve kategoriji, najbolj občutljivi na ustreznost. Opazujte ju pred in po.
• Rešitev ob prvem stiku — ko zahtevki vseeno pridejo, ali vaša odhodna sporočila kupcu dajo dovolj, da podpora to zapre z enim odgovorom?

Kje se vklopi Omnisend

Vse to je odvisno od tega, da so podatki o naročilu na voljo orodju, ki pošlje sporočilo — kar je natanko razlog, zakaj morata trženje in podpora brati isti zapis o kupcu. To argumentiram v celoti v zakaj morata trženje in podpora deliti podatke o kupcih. V praksi Omnisend sinhronizira podatke o naročilih in izdelkih iz vaše trgovine, tako da se lahko tok sklicuje na točne artikle, status dostave in dogodke dostave ter se razveji glede na njih prek e-pošte in SMS. Zgraditi sporočilo, ki pokaže pravi izdelek in živo sledenje, je stvar vstavljanja polj, ne izvažanja preglednice.

Omejitev, vredna omembe: podatki so tako dobri, kot jih napajata vaša trgovina in prevoznik. Če vaša izpolnitev ne vrača sledenja, ga nobeno orodje za e-pošto ne more izmisliti. Najprej naj podatki stečejo; ustreznost sledi. Omnisend je pridruženi partner Shopimationa in ga uporabljam v lastnih trgovinah točno za to vrsto sporočanja, zavedajočega se naročil.

Vaš naslednji korak

Izberite svoje eno podporno sporočilo z največjim obsegom — verjetno e-pošto o dostavi ali ponakupno e-pošto — in naštejte, katere podatke o naročilu trenutno uporablja proti temu, kaj bi lahko. Dodajte tisto eno polje, ki bi odgovorilo na največ vprašanj (običajno sledenje ali resničen datum dostave), in opazujte nadaljevanja. Nato poglejte gorvodno, zakaj je splošna različica sploh ustvarjala zahtevke: zakaj kupci kontaktirajo podporo, ko so avtomatizirani emaili preveč splošni.