Nem kellett CRM: négy kis automata hozta a haszon nagy részét — és mikor kell mégis rendszer
A legrégebbi automatizálási projekt, amibe belefogtunk, egy CRM-terv volt. Négy fázis, ütemezés, világos ígéret: legyen egy helyen az ügyfél, a kapcsolattartás és a nyitott ügy. A terv soha nem indult el. Mire elindulhatott volna, négy kis automata már kiszállította azt a hasznot, amiért a CRM-et be akartuk vezetni — a tervet pedig egy mondattal archiváltuk: a hatókörét más rendszerek megvalósították.
Ez nem CRM-ellenes cikk. A CRM jó eszköz, és van öt helyzet, amikor semmi nem pótolja — ezeket a végén tételesen leírjuk. De a kkv-k többségénél a kérdés nem az, hogy „CRM vagy semmi”, hanem az, hogy melyik fájdalmat akarjuk megszüntetni, és a legolcsóbb megszüntetés tényleg egy új rendszer-e. Nálunk nem az volt, és ez a cikk arról szól, mi lett helyette, milyen számokkal, és hol vannak a határai.
A CRM-terv, amit archiváltunk — és miért nem kár érte
A terv négyfázisú volt, és jól nézett ki. A CRM ígérete négy funkcióban foglalható össze, és mind a négy valódi fájdalomra válaszol:
- Egységes ügyfélkép: egy helyen lássuk, ki az ügyfél, milyen elérhetőséggel, milyen előzménnyel.
- Tevékenység-napló: legyen nyoma annak, ki mikor beszélt vele és miről.
- Nyitott ügyek követése: ne álljon meg csendben egy folyamat azért, mert mindenki azt hitte, a másiknál van.
- Szegmentált listák: lehessen célzottan megszólítani egy jól meghatározott kört.
Az archiválás oka nem az volt, hogy a terv rossz lett volna. Az volt, hogy mind a négy fázis kapott egy olcsóbb választ, mielőtt a fázis elindult volna. Amikor a maradék hasznot nézve feltettük a kérdést, hogy megéri-e még a bevezetés, a válasz nem jött ki.
Érdemes kimondani, mibe kerül valójában egy CRM-bevezetés, mert a döntés általában rossz számon dől el. A licenc a legkisebb tétel. A nagyobbak: az adatmigráció, a törzsadat-tisztítás (mert a hibás adat a régi helyről átköltözik az újba), a folyamatok újratervezése, a betanítás — és a legnagyobb, az adopció. Egy rendszer csak akkor tud bármit, ha az emberek tényleg abban dolgoznak. Ha nem, akkor a cég kifizette a rendszert, és kapott egy újabb helyet, ahol hiányzik az adat.
Amikor egy csapat nem abban a rendszerben rögzít, amiből a vezetőség mér, minden arra épülő mutató vakká válik. Ezt mértük is: a részleteket az adatminőségről szóló cikkünkben írtuk meg. A tanulság ide is érvényes: a rendszer nem hoz létre fegyelmet, csak láthatóvá teszi a hiányát.
A négy kis automata, ami a CRM-terv hasznának nagy részét kiszállította
A négy automata nem egy terv részeként készült. Egymástól függetlenül, más-más fájdalomra születtek, több hónap alatt — és utólag derült ki, hogy együtt a CRM mind a négy ígéretére adnak választ.
| CRM-funkció | Mi lépett a helyébe | Mit csinál | Mérhető állapot |
|---|---|---|---|
| Egységes ügyfélkép | Partnertörzs-felmérés — az ügyféladat állapota | Végigméri a teljes partneradatot, és hibaosztályonként listázza, mi rossz benne | 44 507 partner átnézve, az e-mail-címek 35,7%-a hibás |
| Tevékenység-napló | Hívásrögzítő kérdéssor az ügyfélszolgálaton | A bejövő hívásból strukturált híváslap lesz, felelőssel és esemény-történettel | Az első nyolc nap éles próbaüzemében 89 híváslap és 248 esemény |
| Nyitott ügyek követése | Elakadt és meghiúsult ügyletek havi értesítője | Havonta, értékesítőnként személyre szabva kiküldi, mi állt meg és mi hiúsult meg | Induláskor 93 elakadt és 224 meghiúsult ügylet |
| Szegmentált listák | Havi ügyféllista-automata | Szabálykönyv szerint állítja elő a havi célcsoport-listát, ellenőrző kapukkal | Egy havi zárás 502 sor, mind a 9 ellenőrző kapu kifogás nélkül |
1. Partnertörzs-felmérés. Az egységes ügyfélkép nem szoftverkérdés, hanem adatminőségi kérdés. Mielőtt bárhova összegyűjtenénk az ügyfelet, meg kell tudni, milyen állapotban van az adat. A felmérés 44 507 partnert nézett végig, és azt találta, hogy az e-mail-címek 35,7 százaléka valamilyen okból hibás. Ez a szám önmagában is döntés-értékű: egy CRM ezt az adatot költöztette volna át, nem javította volna meg. A határ: a felmérés megmutatja, mit vinne át változatlanul egy új rendszer; a javítás visszaírása az éles rendszerbe külön, kontrollált lépés. A módszertan a partnertörzs-tisztításról szóló cikkünkben van.
2. Hívásrögzítő kérdéssor. A tevékenység-napló legdrágább része az, hogy valakinek rögzítenie kell. A megoldás nem a fegyelem szigorítása volt. A rögzítés lett a munka része: a telefonos ügyfélszolgálat munkatársa egy kérdéssoron megy végig hívás közben, és ebből keletkezik a strukturált híváslap, felelőssel, státusszal és esemény-történettel, öt szerepkör jogosultságai mellett. Az első nyolc nap éles próbaüzemében 89 híváslap és 248 esemény keletkezett. A rendszer ma a rögzítést oldja meg: a hívásból strukturált, visszakereshető híváslap lesz. Az üzleti hatást — például az elveszett hívások arányát — ugyanezen a naplón lehet mérni, ahogy telik az idő. A részleteket a hívásrögzítésről szóló cikkben írtuk le.
3. Elakadt és meghiúsult ügyletek értesítője. Ez a legolcsóbb a négyből, és talán a leghasznosabb. Havonta egyszer minden értékesítő kap egy személyre szabott levelet arról, melyik ügylete áll meg csendben, és melyik hiúsult meg. Induláskor 93 elakadt és 224 meghiúsult ügyletet talált; egy későbbi havi kör 147 elakadt és 135 meghiúsult tételt küldött ki hét értékesítőnek, plusz egy külön listát azokról, amelyeknek nem volt gazdájuk. A gazdátlan lista az igazi lelet: ezek azok az ügyek, amelyeket egy CRM sem talált volna meg, ha senki nem nyitja meg.
4. Havi ügyféllista-automata. A szegmentált lista nem lekérdezés, hanem szabálykönyv: mi számít bele, mi nem, mi a kizárás, mi a duplikátum-kezelés. Ez a szabálykönyv nálunk tizenkét változatot élt meg, mire véglegessé vált, és ma nyolc szabályból és huszonegy rögzített döntésből áll. Az automata minden hónap utolsó napján lefut; egy havi zárás 502 soros listát adott, és mind a kilenc beépített ellenőrző kapu egyetlen kifogást sem jelzett. A bevezetéskor a rendszer a kézi listát 711/712 egyezéssel reprodukálta — ez volt a bizonyíték, hogy a szabálykönyv tényleg azt írja le, amit az ember csinált.
A négy automata együtt a CRM-terv hasznának a nagy részét kiszállította — és amit nem, arról tudjuk, hogy mi hiányzik. Azzal a különbséggel, hogy nincs új felület, amit meg kell tanulni, és nincs új hely, ahová rögzíteni kell.
Miért működött ez jobban, mint egy új rendszer
Négy oka volt, és ezek a saját cégében is ellenőrizhetők.
1. Nem kellett új helyre rögzíteni. Mindegyik automata a meglévő rendszerekből olvas, és levélben vagy egy szűk felületen ad eredményt. A kollégák ugyanúgy dolgoznak, ahogy eddig. Ez veszi ki a bevezetés legnagyobb kockázatát: nincs adopciós harc, mert nincs mit elfogadni.
2. Mindegyik külön is megérte, és külön is elhagyható. Ha az ügylet-értesítő nem vált be, azt egyedül lehet leállítani; a másik három megy tovább. Egy CRM-nél ez nem opció: ott a bevezetés egyben áll vagy bukik, és ha félúton derül ki, hogy nem működik, az egész befektetés kérdésessé válik.
3. Az éles rendszerből olvasnak. Az éles vállalatirányítási rendszerhez alapértelmezésben olvasásra kapcsolódunk; ahol írás kell, az külön, kontrollált és naplózott döntés. Ennek gyakorlati oka van: az olvasás visszafordítható, az írás nem. Egy olvasó automata legrosszabb esetben rossz levelet küld — az javítható. Egy rossz írás egy húszéves rendszerben adatvesztés.
4. Hetekben mérhető, nem negyedévekben. A hívásrögzítő első éles változata egy héten belül hat frissítést élt meg, mert a használók napi visszajelzései azonnal beépültek. Ez a tempó egy nagy rendszer bevezetésénél elérhetetlen — és pont ez a tempó dönti el, hogy egy eszközt használnak-e.
A belső mondás úgy szól, hogy harminc kis automata többet ér, mint egy nagy rendszer — de csak akkor, ha valaki figyeli őket. Ez a kikötés komoly, és ez a megközelítés valódi ára. A saját gépünkön ma negyven ütemezett automata fut, és havonta több száz levelet küldenek ki; ha egy közülük elhallgat, azt észre kell venni. Ezért van a rendszerek mellett egy vékony üzemeltetési réteg: napi és heti összesítő, néma-hiba őr, riasztás. Arról, hogy ez pontosan mit takar, külön cikkünk szól: mit fedez az üzemeltetési havidíj.
Az ellenérv, amit komolyan kell venni: sok kis automata szétszórt tudás. Ezért tartozik minden automatához leírás és leltár: mit csinál, mit olvas, ki a gazdája. Ettől lesz átadható — a rendszerek az Ön fiókjaiban és szerverein futnak, dokumentálva. Ezt nem az oldja meg, ha mindent egy nagy rendszerbe teszünk.
Mikor kell mégis CRM — öt helyzet, amikor az automata kevés
A kis automaták akkor működnek, ha van egy rendszer, amiből olvasni lehet, és van egy folyamat, ami többé-kevésbé áll. Ahol ez nincs meg, ott az automata csak tüneti kezelés. Öt ilyen helyzetet látunk.
| Helyzet | Miért kevés az automata | Mit érdemes tenni |
|---|---|---|
| Az értékesítőnek magának kell rögzítenie, és nincs hol | Nincs miből olvasni: az adat fejben és jegyzetfüzetben van | Kell egy hely, ahol a munka közben keletkezik az adat — ez lehet CRM vagy célszoftver |
| A csapat egy másik rendszerben dolgozik, mint amiből mérünk | Az automata a rossz forrásból olvas, és magabiztosan hibázik | Előbb döntse el, melyik az igazság forrása, és onnan mérjen |
| Sok felhasználónak kell közös, élő állapotot látnia és módosítania | A levél egyirányú: nem tud közös állapotot tartani | Felület kell jogosultsággal és eseménynaplóval — akkor már rendszert épít |
| Az ügyfélnek is látnia kell a folyamatot | A belső automata nem ügyfél-felület | Portál vagy ügyfélkapu kell, a hozzá tartozó adatvédelmi kerettel |
| Maga a folyamat nincs definiálva | Az automata rögzíti a kaotikus működést, csak gyorsabban | Előbb folyamat-felmérés, utána eszköz |
A harmadik sor a legérdekesebb, mert ez történt velünk is. A hívásrögzítő, amikor közös állapotot, öt szerepkör jogosultságát és esemény-történetet kapott, lényegében egy nagyon szűk, egy folyamatra szabott rendszer lett. A különbség a terjedelemben van: egyetlen folyamatot fed le, azt viszont pontosan. Nem azt állítjuk, hogy rendszert soha nem kell építeni — azt, hogy előbb a legszűkebbet kell megépíteni, ami a fájdalmat megszünteti.
Az ötödik sor a leggyakoribb. Ha a folyamat nincs kimondva, akkor egy CRM bevezetése tulajdonképpen egy folyamat-tervezési projekt, amit egy szoftver ütemezése hajt — ez a legdrágább módja a gondolkodásnak. Nálunk ilyenkor egy folyamat-felmérés az első lépés, gyakran a munkatársak meghallgatásából; a módszert a folyamat-auditról szóló cikkünkben írtuk le.
Hat kérdés, amivel a saját cégében eldöntheti
Ez a hat kérdés nem elmélet: ezekre a válaszokra szoktuk megmondani, hogy automata vagy rendszer a helyes lépés. Mindegyikre egy mondatos válasz kell, nem elemzés.
| # | Kérdés | Ha erre hajlik a válasz, automata elég | Ha erre, rendszer kell |
|---|---|---|---|
| 1 | Hol keletkezik ma az adat, amit látni akar? | Egy meglévő rendszerben, ahol amúgy is dolgoznak | Sehol: fejben, jegyzetben, üzenetben |
| 2 | Hányan kell, hogy egyszerre lássák és módosítsák? | Néhányan, és elég, ha időnként megkapják | Sokan, folyamatosan, közös állapoton |
| 3 | Mi a konkrét fájdalom, amit meg akar szüntetni? | Egy-két nevesíthető ismétlődő hiba vagy kézi kör | Általános érzés, hogy nincs rend |
| 4 | Van-e leírt folyamat, vagy csak szokás? | Van, akár íratlanul is, de egyöntetűen | Nincs, és mindenki máshogy csinálja |
| 5 | Az ügyfélnek is látnia kell valamit? | Nem, kizárólag belső használat | Igen, ügyfél-felület kell |
| 6 | Ki lesz a gazdája fél év múlva? | Van név, és az illető tudja, mit kap tőle | Nincs válasz — ilyenkor egyik sem fog működni |
A hatodik kérdésre érdemes külön figyelni. A leggyakoribb bevezetési kudarc nem technikai: a rendszernek vagy az automatának nincs gazdája, ezért fél év múlva senki nem nézi meg, hogy jó adatot ad-e. Ez az egyetlen kérdés, amire nemleges válasz esetén mi is azt mondjuk, hogy ne kezdjen bele egyikbe sem.
Ha a válaszok fele-fele arányban oszlanak, az általában azt jelenti, hogy két külön problémáról van szó, és külön is kell kezelni őket: az egyikre elég egy automata, a másikra idővel tényleg rendszer kell. Ez a leggyakoribb kimenet, és ez a legolcsóbb is.
Gyakori kérdések
Mennyibe kerül egy CRM bevezetése egy kkv-nál?
A licenc jellemzően a teljes költség kisebb része. A nagyobb tételek az adatmigráció, a törzsadat-tisztítás, a folyamatok újratervezése és a betanítás, ezekhez jön a fenntartás: a havi licenc, a támogatás és az, aki karbantartja. A legnagyobb kockázat az adopció: ha a csapat nem abban dolgozik, a rendszer nem tud semmit. Ezért érdemes a döntés előtt kiszámolni, mennyi eredmény érhető el a meglévő rendszerekből.
Mi az a négy automata, ami kiváltotta a CRM-tervet?
Egy partnertörzs-felmérés az adatminőségre, egy hívásrögzítő kérdéssor a strukturált tevékenység-naplóra, egy havi értesítő az elakadt és meghiúsult ügyletekről, és egy havi ügyféllista-automata a szegmentált listákra. Egyik sem a CRM-terv részeként készült: külön-külön, más-más fájdalomra születtek.
Nem lesz káosz sok kis automatából?
De, ha nincs gazdájuk és nincs leltár. Ezért tartozik hozzájuk egy vékony üzemeltetési réteg: leírás arról, melyik mit csinál, napi és heti összesítő a futásokról, és őr arra az esetre, ha egy automata elhallgat. Ez az üzemeltetési havidíj tartalma.
Honnan tudom, hogy nekünk CRM kell-e?
A legjobb próba az, hogy hol keletkezik ma az adat. Ha egy meglévő rendszerben, ahol a kollégák amúgy is dolgoznak, akkor az eredményhez általában elég egy lekérdezés és egy ütemezett levél. Ha az adat sehol nem keletkezik, csak fejben és jegyzetben él, akkor kell egy hely, ahol keletkezni fog — ott a CRM a helyes válasz.
Ezek az automaták írnak az éles rendszerbe?
Alapértelmezésben nem. Az éles vállalatirányítási rendszerhez olvasásra kapcsolódunk, és ahol írásra mégis szükség lenne, az külön, kontrollált és naplózott döntés, saját jóváhagyással. A gyakorlati ok egyszerű: egy hibás olvasás javítható, egy hibás írás nem.
Mennyi idő alatt készül el egy ilyen kis automata?
Az első használható változat hetekben mérhető, nem negyedévekben: a hívásrögzítő első éles változata egy héten belül hat frissítést élt meg a használók visszajelzéseiből. A szabályok csiszolása viszont hónapokig tart — a havi listánk szabálykönyve tizenkét változatot élt meg, mire véglegesnek nyilvánítottuk.
A következő lépés: írja össze, mit várna a CRM-től
Mielőtt bárki demót mutat Önnek, csinálja meg ezt a húsz perces gyakorlatot. Írja le egy lapra, mi az a három dolog, amit egy CRM-től várna. Ne funkciót írjon, hanem eredményt: „lássam, melyik ügyfél nem hallott rólunk fél éve”, „ne álljon meg csendben egy ajánlat”, „tudjak célzottan megszólítani egy kört”.
Utána tegye fel mindháromra a kérdést: hol van ma az az adat, amiből ez kiszámolható? Ha az adat már létezik valamelyik rendszerében, akkor az eredményhez általában elég egy lekérdezés és egy ütemezett levél. Ha az adat nincs meg sehol, akkor viszont a CRM a helyes válasz — de akkor a bevezetés valódi feladata nem a szoftver, hanem az, hogy az adat elkezdjen keletkezni.
Nálunk egy ilyen kör így néz ki: megnézzük, mi van a meglévő rendszerekben, kiválasztjuk azt a két-három eredményt, amelyik a legtöbb fájdalmat szünteti meg, és megépítjük a legkisebb dolgot, ami ezeket kiszállítja. Ha az elemzésből az jön ki, hogy rendszer kell, akkor a javaslatunk is rendszer lesz. Egy elhatárolás a végére: ez a cikk egy dobozos CRM bevezetéséről szól, nem a meglévő ügyfélkezelés automatizálásáról — az utóbbi külön tétel, saját árral. A megközelítés teljes képe az AI-automatizálás útmutatóban van, a nagyságrendekhez pedig az árakat bemutató cikk és a megtakarítás-kalkulátor ad kiindulást.