E-pošta strankam iz CRM-ja: pošljete z enim klikom, opozorila pridejo pozneje

Pisanje strankam je ena od stvari, ki jih počnemo najpogosteje, in ena od tistih, pri katerih najlažje izgubimo čas. Ko smo v naš CRM vgradili urejevalnik e-pošte, smo zato od njega zahtevali dvoje: da predlaga osnutek, napisan z umetno inteligenco, in da preveri kakovost besedila, preden sporočilo odide. Prva zahteva je stekla gladko. Druga nas je prisilila v načrtovalsko odločitev, ki jo je vredno opisati, saj nasprotuje nagonu vsakogar, ki razvija orodja: preverjanja kakovosti nikoli ne ustavijo pošiljanja.

Kaj zna urejevalnik

Ko mora kdo iz ekipe pisati stranki, CRM predlaga osnutek. Ta ni enak za vse: sistem se uči sloga vsakega člana ekipe. Kdor piše jedrnato, dobi jedrnate predloge, kdor je bolj zgovoren, dobi bolj sproščene. Cilj je, da sporočilo po pošiljanju zveni kot oseba, ki ga podpiše, in ne kot obrazec.

Druga stvar, ki jo urejevalnik zna, je pomnjenje. Za vsako stranko in vsako nepremičnino beleži, kaj ji je bilo že poslano. Zdi se podrobnost, a prav to prepreči sporočilo, ki ponavlja že poslane informacije ali kot novost predstavlja nekaj, kar stranka že dolgo pozna. Kdor prejme ponavljajoče se sporočilo, takoj razume, da se ga na drugi strani nihče ne spominja. S pomnjenjem po nepremičninah se osnutek začne tam, kjer smo ostali.

Nato je tu še preverjanje kakovosti: urejevalnik besedilo ponovno prebere in opozori na tisto, kar bi se po njegovem mnenju dalo izboljšati.

Odločitev: klik zmaga

Pravo vprašanje je bilo: kaj se zgodi, ko preverjanje najde nekaj, kar mu ni všeč? Najočitnejši odgovor, ki se porodi vsakomur, ki piše programsko opremo, je vse ustaviti, dokler težava ni odpravljena. Siv gumb, rdeče sporočilo, »popravite pred pošiljanjem«.

Naš vodja se je odločil ravno nasprotno. Sporočilo se pošlje z enim klikom, vedno. Opozorila pridejo pozneje, in to kot predlogi, ne kot ukazi. Kdor je sporočilo napisal, jih prebere in jih upošteva naslednjič ali pa jih prezre, če meni, da ima prav.

Sprva se odločitev morda zdi korak nazaj. Imamo orodje, ki prepozna besedilo, ki bi ga lahko izboljšali, pa ga vseeno pustimo oditi? Da, in razlog je zanimivejši od same odločitve.

Zakaj blokada zaradi sloga škodi

Sistem, ki blokira zaradi sloga, ljudi nauči, da ga obidejo. Tako je pri vsakem orodju: če se vam preverjanje postavi po robu, ko se vam mudi in ste prepričani v to, kar pišete, se hitro naučite, kako ga utišati. Stavek preoblikujete, da gre skozi, odstranite besedo, ki ga sproži, odprete drug program in sporočilo pošljete od tam. Rezultat je slabši kot prej: besedilo se ni izboljšalo, poleg tega pa ste se naučili, da je sistem ovira, ki jo je treba preskočiti.

Obstaja še manj viden učinek, po našem mnenju hujši. Če blokira vse, nič zares ne blokira. Ko se človek navadi, da vidi rdeče sporočilo zaradi vejice ali predolgega stavka, neha razlikovati med opozorilom, ki je pomembno, in tistim, ki ni. Prave blokade izgubijo vrednost, ker jih ljudje sprejemajo z enako nestrpnostjo kot nepotrebne.

Preverjanje sloga, še tako dobro narejeno, ostaja mnenje. Lahko ima velikokrat prav, a nima konteksta, ki ga ima tisti, ki stranko pozna. In mnenje nikoli ne bi smelo imeti moči, da ustavi delo.

Edina blokada, ki ostaja

Od vseh mogočih blokad je ostala samo ena: preklicana privolitev. Kdor je prosil, naj ga ne kontaktiramo več, mu ne pišemo. Tu urejevalnik ne predlaga in ne opozarja pozneje: sporočila preprosto ne pusti oditi.

Razlika s preverjanji kakovosti je jasna. Slog je stvar presoje, presoja pa pripada tistemu, ki piše. Spoštovanje izrecne zahteve stranke ni stvar presoje. Ni dobrega razloga, da bi pisali nekomu, ki je prosil, naj ne prejema več naših sporočil, in nobena naglica tega ne opravičuje.

Prav zato, ker je edina, ima ta blokada težo, ki je med desetimi drugimi ne bi imela. Ko se urejevalnik ustavi, tisti, ki piše, ve, da to ni muhavost orodja. Ničesar ni treba obiti in nihče nima skušnjave, da bi to poskusil.

Opozorila pozneje, ne prej

Če opozorila premaknemo na čas po pošiljanju, se spremeni tudi način, kako jih beremo. Pred pošiljanjem je opozorilo ovira: beremo ga z nestrpnostjo, da bi se ga čim prej znebili. Pozneje, ko je sporočilo že odšlo, je komentar k nečemu, kar smo naredili, in ga beremo bolj umirjeno. To je razlika med sodelavcem, ki vam iztrga list iz rok, in sodelavcem, ki vam po opravljenem delu reče: »Naslednjič bi poskusil takole.«

Urejevalnik je skratka sodelavec, ki besedilo ponovno prebere, ne čuvaj, ki odloča. Osnutki pomagajo začeti, pomnjenje preprečuje ponavljanje, opozorila pa pomagajo, da se sčasoma izboljšujemo. Nobena od teh treh stvari ne stoji med človekom in gumbom za pošiljanje.

Kaj smo se naučili

Lekcija presega e-pošto in jo zdaj uporabljamo pri vsakem orodju, ki ga razvijemo:

• Ločevanje pravil od nasvetov. Pravilo je nekaj, česar ne storimo nikoli, iz nobenega razloga. Nasvet je nekaj, kar se običajno splača storiti. Če ju pomešamo v isti mehanizem, pokvarimo oboje.
• Čim manj blokad. Vsaka dodatna blokada odvzame moč tistim, ki so pomembne. Če ostane ena, jo vsi jemljejo resno.
• Uporabnik naj ne plačuje za negotovost orodja. Če sistem ni prepričan, da ima prav, se ne sme vesti, kot da ga ima.
• Zaupanje tistim, ki pišejo. Člani ekipe poznajo stranke bolje kot katero koli samodejno preverjanje. Orodje jih mora narediti hitrejše in pozornejše, ne pa nadomestiti njihove presoje.

Če razvijate kaj podobnega, bo skušnjava, da bi povsod postavili blokirajoče preverjanje, močna, ker se zdi najpreudarnejša izbira. Po naših izkušnjah je ravno nasprotno: prava preudarnost je v tem, da skrbno določimo tistih nekaj stvari, ki jih nikoli ne smemo storiti, vse drugo pa pustimo prosto.