Vaše marketinške avtomatizacije in vaš sistem podpore morajo brati iz istega zapisa o kupcu, kajti v trenutku, ko tega ne počnejo, vaša trgovina začne pošiljati promocijska e-poštna sporočila ljudem sredi pritožbe, prilagajati ponudbe okrog naročil, ki so bila vrnjena za denar, in obravnavati besnega kupca kot zadovoljnega. Deljeni podatki so tisto, kar promocijskemu toku omogoča, da ve, kdaj zadržati, ko je zahtevek za podporo odprt, in kar odgovoru podpore omogoča, da ve, kaj je kupec dejansko kupil in kdaj. Oba sistema imejte v ločenih silosih in vaša avtomatizacija, naj bo še tako pametna, bo sčasoma storila nekaj tako gluhega za ton, da izgubi kupca, ki ste ga že plačali, da bi ga pridobili. Ta stran govori o tem, zakaj morajo podatki teči v obe smeri, kaj se pokvari, ko ne, in kako to povezati brez šestmesečnega integracijskega projekta.

Razkol, ki tiho škoduje dobrim kupcem

V večini trgovin sta marketing in podpora zrasla ločeno. Marketing živi v e-poštni platformi. Podpora živi v službi za pomoč ali poštnem predalu. Vsak ima svoj pogled na kupca in nobeden ne vidi drugega.

To je v redu, dokler kupec ne stori povsem človeške stvari, da je v dveh stanjih hkrati, torej kupec in težava. Naročila je jakno za 300 €, prispela je poškodovana, tri e-poštna sporočila globoko je z vašo ekipo podpore in poskuša urediti vračilo. Medtem vaša marketinška avtomatizacija, ki o zahtevku ne ve ničesar, vidi nedaven nakup visoke vrednosti in sproži veselo navzkrižno prodajo: “Vam je bila jakna všeč? Tukaj je ujemajoč se šal, danes 10 % popusta!” Zanjo se ta e-pošta bere kot vaša trgovina, ki se ji smeji, medtem ko drži njen denar. Tega ne razume kot “dva nepovezana sistema”. Bere jo kot eno podjetje, ki ne posluša.

To je škoda. Redko je to napaka, ki bi jo opazili pri testiranju, ker sta oba sistema storila natanko to, kar jima je bilo naročeno. Le drug o drugem jima ni bilo povedano.

Zakaj očitne rešitve ne držijo

Nagon je zakrpati to ročno. Nekdo v podpori se spomni ustaviti novice za jezne kupce. Tedenski izvoz premakne seznam iz enega orodja v drugo.

Ročno krpanje odpove iz istega razloga kot vse ročno krpanje: količina in časovnica. Oseba lahko zatre marketing za eno glasno pritožbo, ki jo je slučajno videla. Ne more tega storiti za štirideset tišjih zahtevkov, ki se ta teden premikajo skozi čakalno vrsto, in zagotovo tega ne more storiti v desetih minutah med tem, ko pristane pritožba, in tem, ko se sproži navzkrižna prodaja. Avtomatizacija teče na podatkih, ne na spominu, in če podatki o odprtem zahtevku nikoli ne dosežejo marketinškega orodja, nobena količina dobrih namenov ne ustavi napačne e-pošte.

Druga nerešitev je nakup več orodij. Boljša služba za pomoč in boljša e-poštna platforma, ki se še vedno ne pogovarjata med seboj, vam preprosto dasta dva boljša silosa. Težava ni bila nikoli kakovost katerega koli od sistemov. Vrzel med njima je.

Kje razkroj izgublja denar

Izguba se pokaže na treh mestih in nobeno se ne pojavi na poročilu z oznako “davek na silose”.

• Zadrževanje. Marketing kupcu z odprto pritožbo merljivo zviša verjetnost, da odide, torej ste porabili strošek pridobitve, da bi nekoga osvojili, nato pa porabili maržo za e-pošto, ki ga odriva stran. Najdražja avtomatizacija je tista, ki razjezi kupca, ki ga že imate.
• Zapravljena prilagoditev. Marketing, ki ne vidi vračil in vrnitev, še naprej gradi priporočila na naročilih, ki so bila poslana nazaj. “Več takega kot vaš nedavni nakup” je slabše kot neuporabno, ko je nedavni nakup ravno stvar, ki so jo sovražili.
• Podpora, ki začne iz nič. Podatki morajo teči tudi v drugo smer. Ko agent podpore ne vidi kupčeve zgodovine naročil, vrednosti nakupov ali katera avtomatizirana sporočila so že šla ven, znova sprašuje vprašanja, na katera trgovina že pozna odgovor. Ta počasna, splošna podpora je sama po sebi razlog, da ljudje odidejo, kar je nit, raziskana v zakaj kupci kontaktirajo podporo, ko so avtomatizirana e-poštna sporočila preveč splošna.

Praktična rešitev: en zapis, ki ga berata obe strani

Ne potrebujete projekta podatkovnega skladišča. Potrebujete, da se oba sistema strinjata, kdo je kupec, in da si delita nekaj odločilnih signalov.

1. Poenotite se na kupcu, običajno na e-poštnem naslovu. Oba sistema naj se navežeta na isti identifikator, tako da marketinški profil in zgodovina podpore neke osebe kažeta na enega človeka, ne na dva polovična zapisa.

2. Potisnite status podpore v marketing. Signali, ki najbolj štejejo v smeri podpora → marketing: ali ima ta kupec odprt zahtevek, nerešeno pritožbo ali čakajoče vračilo? Ti postanejo pogoji zatiranja, marketinški ekvivalent zastavice “ne moti”.

3. Potisnite podatke o naročilu in vedenju v podporo. V smeri marketing/trgovina → podpora: zgodovina naročil, življenjska vrednost, katere avtomatizacije so se že sprožile. Agent, ki vidi “včeraj smo ji že poslali opombo o zamudi dostave”, poda skladen odgovor namesto protislovnega.

4. Deljene signale spremenite v pravila. Podatki so vredni imeti le, če spremenijo vedenje. Dve pravili si takoj zaslužita svoje mesto: ustavite promocije, medtem ko je pritožba odprta, in izključite kupce z nerešenimi težavami iz kampanj s popusti. Razlogovanje in nastavitev zanju živita v kdaj naj težava s podporo kupcem ustavi marketinška sporočila in kako izključiti kupce z odprtimi pritožbami iz promocij.

5. Deljene podatke uporabite za prilagajanje, ne le za zatiranje. Ko podatki o naročilu dosežejo vsako sporočilo, se lahko vaše avtomatizacije podpore in po nakupu sklicujejo na dejanski izdelek in situacijo, kar je prednost, obravnavana v uporaba podatkov o naročilu za bolj relevantna sporočila podpore.

Kaj avtomatizirati

• Sprožilec: dogodek podpore, torej zahtevek odprt, pritožba označena, vračilo zahtevano, zahtevek rešen.
• Segment: živ segment “ima odprto težavo”, v katerega kupci vstopajo in ga zapuščajo samodejno, ko se spreminja status njihovega zahtevka.
• Dejanje: dokler so v tem segmentu, so izpuščeni iz promocijskih tokov in tokov navzkrižne prodaje; transakcijska in storitvena sporočila se še vedno pošiljajo. Ko se zahtevek reši, se vrnejo v običajni marketing, rešen zahtevek pa lahko sam sproži premišljeno nadaljevanje, obravnavano v kaj poslati po tem, ko je zahtevek za podporo rešen.
• Smer: zgodovina naročil in sporočil teče v pogled podpore, tako da agenti odgovarjajo s polnim kontekstom.
• Cilj: noben kupec nikoli ne dobi promocijske e-pošte, ki je v protislovju z njegovo trenutno izkušnjo z vami, in noben agent nikoli ne odgovarja na slepo.

Primer iz trgovine

Trgovina z izdelki za dom poveže svojo službo za pomoč s svojo e-poštno platformo prek deljenega e-poštnega naslova. Zgradijo en segment: “odprta težava s podporo”.

Kupec prijavi razpokano vazo. Zahtevek se odpre in v roku ure pristane v segmentu “odprta težava s podporo”. Tedenska promocijska kampanja in navzkrižna prodaja po nakupu pred pošiljanjem obe preverita segment in ga preskočita. Njegova edina sporočila so od podpore, ki dela na težavi. Tri dni pozneje se nadomestek odpošlje, zahtevek se zapre in on samodejno izstopi iz segmenta. Naslednji teden ga kampanja doseže običajno, zdaj ko je znova zadovoljen kupec. Nikoli ni prejel e-pošte “razvajajte se!”, medtem ko je strmel v razbito vazo. (Ponazoritveni primer, prilagodite svojim sistemom in logiki segmentov.)

Kako to izmeriti

• Promocijska pošiljanja kupcem z odprtimi težavami – to naj bo pri nič ali blizu nič, ko je pravilo zatiranja aktivno. Če ni, vaša sinhronizacija podatkov zaostaja.
• Stopnja odhajanja kupcev, ki so imeli težavo s podporo – primerjajte pred in po povezavi sistemov; gluh marketing med pritožbo je gonilnik odhajanja, ki ga zdaj lahko odstranite.
• Kakovost prvega odziva v podpori – teže količinsko opredeljivo, a manj odgovorov “mi lahko poveste, kaj ste naročili?” pomeni, da podatki o naročilu dosegajo agente.
• Pritožbe o nepomembnem ali časovno neustreznem marketingu – mehak signal, a padajoče število pomeni, da se davek na silose krči.

Kako se v to vpne Omnisend

Osnovna zahteva je, da signal podpore lahko doseže vašo marketinško avtomatizacijo in deluje kot pogoj zatiranja. Omnisend, orodje, ki ga poganjam v svojih lastnih trgovinah, potem ko sem ga preizkusil proti Klaviyu, podpira segmente in pogoje tokov, ki jih lahko poganja povezana služba za pomoč, tako da status “odprta težava” lahko zadrži kupca zunaj promocijskih tokov, medtem ko še vedno dovoli storitvena sporočila. Prav tako potegne podatke o naročilu v sporočila, kar pokrije drugo smer za avtomatizacije po nakupu in tiste ob podpori.

Pošten pridržek: nobena e-poštna platforma čarobno ne ve za zahtevek v ločeni službi za pomoč. Ta povezava, prek domače integracije, deljene platforme ali lahke avtomatizacije med njima, je pravo delo, in vredno jo je enkrat opraviti kot je treba. Omnisend poskrbi, da marketinška stran ukrepa glede na podatke; vi še vedno morate spraviti podatke v pretok. Omnisend je pridruženi partner Shopimation, priporočen iz dejanske uporabe, njegov brezplačni paket pa je dovolj, da zgradite in preizkusite segment zatiranja, preden se zavežete.

Vaš naslednji korak

Pošljite si test: odprite zahtevek za podporo kot lažni kupec, nato preverite, ali bi vaša naslednja načrtovana kampanja to osebo še vedno poslala e-pošto. Če je odgovor da, si vaši sistemi ne delijo enega signala, ki najbolj šteje. Najprej popravite to pravilo zatiranja, nato zasnujte, katere skupine kupcev naj deljeni podatki oblikujejo, z segmenti kupcev, ki jih mora ustvariti vsaka spletna trgovina.