Клиенттік деректерден автоматтандырылған CRM-сценарийлерге дейін: клиенттің өмірлік циклін басқару жүйесі қалай жобаланады

CRM-автоматтандыруды көбіне хабарламалар тізбегі ретінде елестетеді: клиент тіркелді — сәлемдесу хатын алды; тауарды себетке салды — еске салу алды; көптен бері сатып алмады — қайта оралу ұсынысын алды.

Бірақ хабарлама — жүйенің тек көрінетін бөлігі.

Оны жібермес бұрын CRM-платформа:

• клиентті сәйкестендіруі
• болған оқиға туралы деректерді алуы
• клиенттің ағымдағы күйін анықтауы
• ондаған шарттар мен ерекшеліктерді тексеруі
• коммуникацияның жалпы қажет екенін түсінуі
• тиісті сценарийді таңдауы
• өзекті тауарды немесе санатты анықтауы
• қолжетімді арналар мен келісімдерді тексеруі
• клиент басқа, маңыздырақ коммуникация алып жатпағанына көз жеткізуі
• қабылданған шешімді тіркеуі
• клиенттің кейінгі әрекеттерін бақылауы
• мақсатқа жеткенде сценарийді тоқтатуы немесе өзгертуі тиіс.

Сондықтан CRM-сценарий — хаттар тізбегі емес. Бұл клиенттік деректер негізінде шешім қабылдайтын орындалатын алгоритм.

Мұндай алгоритмді жобалау бизнес-логиканы, деректер моделін, ассортиментті, CRM-платформаның техникалық мүмкіндіктерін және клиентпен өзара әрекеттесу ережелерін бір басқарылатын жүйеге біріктіруді талап етеді.

Автоматтандырылған CRM-сценарий неден тұрады

Әр сценарийдің негізінде бес элемент бар.

1. Бақыланатын факт

Ақпараттық жүйеде оқиға болды:

• клиент тіркелді
• сатып алу жасады
• тауарды қарады
• тауарды себетке қосты
• жаңа санатқа өтті
• промокод пайдаланды
• мәртебесін өзгертті
• хабарлама алды немесе ашты
• белсенділік танытуды тоқтатты.

Оқиға не болды? деген сұраққа жауап береді.

2. Есептелген күй

Оқиғалар тарихы мен атрибуттар негізінде жүйе клиенттің күйін анықтайды:

• тіркелген, бірақ сатып алу жасамаған
• тек бір сатып алу жасаған
• тұрақты түрде сатып алады
• көптен бері тауар сатып алмаған
• белгілі бір санатқа қызығушылық танытады
• кету қаупі жоғары
• қолжетімді арналар арқылы байланысу мүмкін емес.

Күй қазір клиент туралы не білеміз? деген сұраққа жауап береді.

3. Шешім қабылдау ережесі

Жүйе берілген шарттарды тексереді:

• қажетті күн саны өтті ме
• мақсатты әрекет орындалды ма
• коммуникацияға келісім бар ма
• клиент басқа кампанияда жүр ме
• тауар қолжетімді ме
• жиілік лимиті асқан жоқ па
• клиент қажетті елге, бағдарламаға немесе сегментке жата ма.

Ереже қазір бір әрекет жасау керек пе? деген сұраққа жауап береді.

4. Әрекет

Шарттар орындалса, жүйе:

• email, SMS, push-хабарлама немесе Telegram хабарламасын жібереді
• сайтта дербестендірілген блок көрсетеді
• деректерді сыртқы жүйеге береді
• клиентке атрибут тағайындайды
• техникалық оқиғаны тіркейді
• тапсырма жасайды
• клиентті сценарийдің басқа тармағына өткізеді.

Әрекет жүйе не істеуі тиіс? деген сұраққа жауап береді.

5. Кері байланыс

Әрекеттен кейін жүйе клиентті бақылауды жалғастырады:

• сатып алу жасады ма
• сілтемеге өтті ме
• қалауын өзгертті ме
• коммуникациялардан бас тартты ма
• басқа сегментке өтті ме
• сценарийді жалғастыру себебі жойылды ма.

Кері байланыс біздің әрекеттен кейін клиенттің күйі өзгерді ме? деген сұраққа жауап береді.

Осылайша автоматтандыру тұйық цикл ретінде жұмыс істейді:

оқиға → күйді бағалау → шарттарды тексеру → әрекет → жаңа оқиға → күйді жаңарту.

1. Бизнес-міндетті формалды логикаға аудару

Сценариймен жұмыс CRM-платформа интерфейсінен басталмайды. Алдымен бизнес-міндетті формалданған модельге айналдыру қажет.

Мынадай тұжырымдар:

• сатып алу жиілігін арттыру
• жаңа санаттағы сатылымды дамыту
• белсенді емес клиенттерді қайтару
• екінші сатып алуды ынталандыру
• ұстап қалуды арттыру
• LTV-ді өсіру

қалаған бизнес-нәтижені сипаттайды, бірақ әлі техникалық тапсырма емес.

Мына міндетті қарастырайық:

Екінші сатып алу жасайтын клиенттердің үлесін арттыру.

Бұл процесті автоматтандыру үшін бірқатар сұраққа жауап беру қажет.

Кім жаңа клиент болып саналады?

Бұл мынадай адам болуы мүмкін:

• тіркелген
• есептік жазба жасаған
• алғаш рет сатып алу жасаған
• алғаш рет тапсырысты төлеген
• алғаш рет тапсырысты алған
• белгілі бір санаттағы тауарды алғаш рет сатып алған.

Бұл анықтамалар бір-бірін алмастырмайды.

Бірінші сатып алу деп не саналады?

Мыналарды анықтау керек:

• төленбеген тапсырыстар есепке алына ма
• тоқтатылған тапсырыстар алынып тастала ма
• жеткізілгенге дейін тапсырыс сатып алу болып санала ма
• қайтарулар ескеріле ме
• нөлдік құны бар тапсырыс есептеле ме
• толық қайтару кезінде не болады
• бірнеше тауары бар бір сатып алу бір тапсырыс па, әлде бірнеше транзакция ма.

Егер тауар позициялары қателесіп бөлек сатып алу ретінде саналса, бес тауары бар бір тапсырыс клиентті бірден бес сатып алуы бар сатып алушыға айналдыруы мүмкін.

Сондықтан көрсеткіш әдетте келісілген бизнес-ережелерге сәйкес келетін бірегей аяқталған тапсырыстар саны ретінде есептеледі.

Екінші сатып алу қандай мерзімде күтіледі?

«Екі апта қисынды естіледі» деген себеппен ғана мерзім белгілеуге болмайды.

Ол мыналарға байланысты болуы мүмкін:

• сатып алулар арасындағы әдеттегі интервалға
• бірінші сатып алу санатына
• тауарды пайдалану мерзіміне
• өңірге
• клиент түріне
• маусымдылыққа
• адалдық бағдарламасына
• бірінші сатып алу арнасына
• ұқсас клиенттердің тарихи мінез-құлқына.

Қандай әрекет мақсатты болып саналады?

Мақсат:

• екінші тапсырыс жасау
• оны төлеу
• оны алу
• екінші санаттан сатып алу
• белгілі бір өнімді сатып алу
• ең төменгі сомаға жету
• белгіленген терезе ішінде қайталама сатып алу жасау болуы мүмкін.

Сценарий қашан тоқтауы керек?

Клиент екінші сатып алуды жасағаннан кейін қосымша еске салулар мәнін жоғалтады. Бірақ мыналарды нақтылау қажет:

• сценарий тапсырыс жасалғанда ма, әлде төленгенде ме тоқтайды
• тоқтатылғаннан кейін қайта іске қосыла ма
• клиент үшінші сатып алу сценарийіне ауыса ма
• сатып алу күту кезінде болса не болады
• офлайн-дүкенде жасалған тапсырыс мақсатты болып санала ма.

Осы анықтамалар келісілгеннен кейін ғана міндет алгоритмге айналады.

Мысалы:

Клиент алғашқы аяқталған тапсырысын жасады. Егер одан кейінгі 14 күн ішінде екінші аяқталған тапсырыс болмаса, клиент қосымша шарттарға сәйкес келсе және коммуникация қолжетімді болса, жүйе екінші сатып алуды дамыту сценарийін іске қосады. Екінші аяқталған тапсырыс пайда болған сәтте клиент сценарийден бірден шығарылады.

Бұл тұжырымды деректерге, шарттарға, оқиғаларға және әрекеттерге аударуға болады.

2. Сценарий мақсаты мен шекарасын анықтау

Әр сценарийдің бір негізгі мақсаты болуы тиіс.

Бұл оның бірнеше көрсеткішке әсер ете алмайтынын білдірмейді. Бірақ жүйе қандай әрекет сәттілік болып саналатынын және міндет қашан орындалғанын түсінуі керек.

Екінші сатып алу сценарийі үшін негізгі мақсат:

Бірінші сатып алудан кейін 30 күн ішінде екінші аяқталған тапсырыс жасау.

Қосымша көрсеткіштер:

• бірінші және екінші сатып алу арасындағы уақыт
• екінші сатып алуға конверсия
• орташа чек
• сатып алынған санаттар саны
• мақсатты тауарлар сатып алуының үлесі
• маржиналдылық
• коммуникациялардан бас тарту саны болуы мүмкін.

Сонымен қатар негізгі мақсат үшін нашарлатуға болмайтын шектеуші көрсеткіштерді бекіту керек:

• жазылымнан бас тарту жиілігі
• спам туралы шағымдар
• қайтару үлесі
• маржа
• бір клиентке шаққандағы байланыс саны
• қарама-қайшы ұсыныстар алатын клиенттер үлесі.

Мұндай көрсеткіштерді қорғаныс немесе шектеуші метрикалар деп атайды. Олар негізгі мақсат емес, бірақ нәтижеге қалаусыз тәсілмен қол жеткізілмегенін тексеруге көмектеседі.

Мысалы, жеңілдік екінші тапсырыстар санын арттыруы мүмкін, бірақ бір уақытта маржаны төмендетіп, клиенттерді тек акция кезінде сатып алуға үйретуі мүмкін. Сондықтан «көбірек сатып алу» әрқашан «бизнес үшін жақсы» дегенді білдірмейді.

3. Клиенттің өмірлік цикл моделі

Мақсат анықталғаннан кейін өмірлік цикл моделі жобаланады.

Бөлшек сауда компаниясы үшін ол мынадай болуы мүмкін:

1. Клиент тіркелген, бірақ әлі сатып алмаған.
2. Бірінші сатып алу жасады.
3. Екінші сатып алу жасады.
4. Тұрақты сатып алуға өтті.
5. Белсенділігі төмендеді.
6. Кету қаупінде тұр.
7. Қайта белсендірілді немесе толықтай белсенді емес.

Мұндай схема CRM-ді байланыссыз кампаниялар жиынтығы емес, күйлер арасындағы ауысулар жүйесі ретінде көруге көмектеседі.

Бірақ өмірлік цикл моделі әрдайым өзара бір-бірін жоққа шығаратын мәртебелері бар бір өріс болмауы тиіс.

Бір клиент бір уақытта:

• тек бір сатып алуы болуы
• белгілі бір санатқа қызығуы
• әлеуетті LTV-і жоғары болуы
• email-ге жауап бермеуі
• кету қаупінде болуы
• адалдық бағдарламасына қатысуы мүмкін.

Сондықтан нақты жүйеде әдетте мыналар бірге қолданылады:

• өмірлік циклдің негізгі күйі
• тәуелсіз мінез-құлық белгілері
• динамикалық сегменттер
• есептелген көрсеткіштер
• арналардың техникалық қолжетімділік мәртебелері.

Бұл маңызды айырмашылық.

Күй клиенттің негізгі процестің қай жерінде тұрғанын көрсетеді. Сегменттер мен белгілер бір уақытта болуы мүмкін қосымша сипаттамаларды сипаттайды.

4. Шешім қабылдауға қажетті деректер

Өмірлік цикл жобаланғаннан кейін жүйеге қандай мәліметтер қажет екені анықталады.

Екінші сатып алу сценарийі үшін ең төменгі жиын мыналарды қамтуы мүмкін:

• клиент идентификаторы
• тапсырыс идентификаторы
• тапсырыс күні мен уақыты
• тапсырыс мәртебесі
• сома
• валюта
• тауар құрамы
• тауар санаттары
• бірегей аяқталған сатып алулар саны
• бірінші сатып алу күні
• соңғы сатып алу күні
• коммуникацияға келісімдер
• қолжетімді байланыс деректері
• тіл
• ел
• алынған хабарламалар тарихы.

Бірақ өрістің болуы оны пайдалануға болады дегенді білдірмейді.

Әр көрсеткіш үшін мыналарды білу керек:

• ол қай жүйеден келеді
• қалай есептеледі
• қандай кідіріспен жаңартылады
• дереккөз эталондық па
• өзгерістер қалай өңделеді
• мәннің болмауы нені білдіреді
• қандай уақыт белдеуі қолданылады
• тарихты қалпына келтіруге бола ма.

Мысалы, сатып алу деректері CRM-ге тәулігіне бір рет қана түссе, сценарий тапсырыстан бес минуттан кейін коммуникацияны сенімді тоқтата алмайды. Техникалық архитектура қажетті реакция жылдамдығына сәйкес болуы тиіс.

Бастапқы және есептелген деректер

Жүйе деректердің екі түрін пайдаланады.

Бастапқы деректер сыртқы жүйелерден түседі:

• тапсырыс жасалды
• төлем алынды
• тауар қаралды
• клиент тіркелді
• хабарлама жеткізілді.

Есептелген деректер тарихтан шығарылады:

• сатып алулар саны
• соңғы тапсырыстан кейінгі күн саны
• тапсырыстар арасындағы орташа интервал
• таңдаулы санат
• орташа чек
• акция бойынша сатып алу үлесі
• қайталама сатып алу ықтималдығы
• сегментке тиесілілік.

Bloomreach Engagement клиенттің туынды сипаттамаларына айналатын және сүзгілер мен сценарийлерде қолданылатын агрегаттар, сегментациялар және өрнектер жасауға мүмкіндік береді. Мысалы, агрегат сатып алуларды санай алады, ал өрнек соңғы сатып алудан кейінгі күн санын есептей алады. Bloomreach: Aggregates and running aggregates, Bloomreach: Expressions

Бұл ретте есептеу формалды түрде анықталуы тиіс. Құжаттамасыз purchase_count көрсеткіші жеткіліксіз. Мыналарды білу қажет:

• қандай тапсырыс мәртебелері ескеріледі
• тоқтатулар есепке алына ма
• тесттік транзакциялар алынып тастала ма
• қайтарулар ескеріле ме
• бір тапсырыс бір рет есептеле ме
• есептеу қай кезең үшін орындалады.

5. Триггерді таңдау

Триггер жүйе сценарийді іске қосу мүмкіндігін тексере бастайтын сәтті анықтайды.

Триггерлер әртүрлі болуы мүмкін.

Оқиғалық триггер

Оқиғадан кейін бірден іске қосылады:

• тіркелу
• сатып алу
• тауарды себетке қосу
• тапсырыс мәртебесінің өзгеруі
• тауардың түсуі
• хабарламаны ашу.

Мұндай триггер жылдам реакция қажет болғанда қолайлы.

Мерзімді тексеру

Жүйе кесте бойынша шарттарға сәйкес келетін клиенттерді іздейді:

• күн сайын бірінші сатып алудан кейін 14 күн өткен клиенттерді анықтайды
• аптасына бір рет белсенділіктің төмендеуін анықтайды
• ай сайын өмірлік цикл кезеңін қайта есептейді.

API-триггер

Сыртқы жүйе сигналды тікелей CRM-платформаға береді. Ол сценарийге қажетті параметрлерді қамтуы мүмкін.

Каталогтың өзгеруі

Сценарий тауар өзгергеннен кейін іске қосылуы мүмкін:

• тауар қайтадан қолжетімді болды
• баға төмендеді
• жаңа тауар пайда болды
• оқиға күні жақындады
• қалдық берілген деңгейден төмен түсті.

Bloomreach оқиғалық, мерзімді, API және каталогтық іске қосу механизмдерін қолдайды. Мысалы, каталог тауар қайта пайда болғанда, бағасы төмендегенде немесе жаңа тауар шыққанда сценарийді іске қоса алады. Bloomreach: Introduction to scenarios, Bloomreach: Catalog trigger types

Бірақ маңыздысы:

Триггер коммуникация міндетті түрде жіберілуі керек дегенді білдірмейді.

Ол жүйеге өңдеуге үміткер пайда болғанын ғана хабарлайды.

Триггерден кейін ағымдағы шарттар міндетті түрде қайта тексеріледі. Клиент сатып алып қойған, келісімін қайтарып алған, басқа ұсыныс алған немесе сегментке сәйкес келмей қалған болуы мүмкін.

6. Кіру шарттарын жобалау

Кіру шарттары сценарийге кім кіре алатынын анықтайды.

Екінші сатып алуды дамыту үшін олар мынадай болуы мүмкін:

• дәл бір аяқталған тапсырыс бар
• одан кейін 14 толық күн өтті
• тапсырыс толық қайтарылмаған
• клиент екінші сатып алу жасамаған
• профиль тесттік немесе қызметтік емес
• ел сценарий қамтитын аумаққа кіреді
• клиентте қолжетімді арна бар
• қажетті келісім бар
• жиілік лимитіне жетпеген
• клиент шығаратын сценарийде жоқ
• қажетті деректер толтырылған
• сәйкес ассортимент бар.

Шарттарды бірнеше топқа бөлген дұрыс.

Бизнес-шарттар

Міндетке сәйкестікті анықтайды:

• өмірлік цикл кезеңі
• сатып алулар саны
• әрекетсіздік кезеңі
• санат
• клиент мәртебесі.

Құқықтық және коммуникациялық шарттар

Байланысу құқығы мен мүмкіндігін анықтайды:

• келісім
• қолданыстағы байланыс
• жаһандық тыйымның болмауы
• рұқсат етілген арна
• рұқсат етілген ел.

Техникалық шарттар

Деректердің дайын екенін тексереді:

• идентификатор белгілі
• тіл толтырылған
• тауар бар
• баға берілген
• сілтеме қолжетімді
• интеграция қатесі анықталмаған.

Оркестрациялық шарттар

Басқа сценарийлермен өзара әрекеттесуді тексереді:

• маңыздырақ коммуникация іске қосылмаған
• жиілік асқан жоқ
• қарама-қайшы ұсыныс жоқ
• қажетті интервал сақталған.

Бұл сценарийді ашық етеді. Егер клиент хабарлама алмаса, себебін анықтауға болады: бизнеске сәйкес келмеу, келісімнің болмауы, деректер қатесі немесе басқа кампанияның басуы.

7. Қайта кіру ережелері

Жиі кездесетін қателердің бірі — алғашқы іске қосуды дұрыс баптап, клиент қайта кіре ала ма деген ережені анықтамау.

Бірнеше модель болуы мүмкін.

Тек бір рет кіру

Бірегей кезеңге қолайлы:

• бірінші тіркелу
• бірінші сатып алу
• мәртебеге бірінші рет жету.

Аяқталғаннан кейін қайта кіру

Мысалы, клиент әрбір сәйкес сатып алудан кейін қорды толықтыру сценарийіне қайта кіре алады.

Белгіленген кезеңнен кейін қайта кіру

Мысалы, 90 күнде бір реттен жиі емес.

Жаңа оқиғадан кейін қайта кіру

Алдыңғы данасы аяқталған болса, жаңа тапсырыстан кейін клиент сценарийдің жаңа данасын бастай алады.

Клиент сценарий ішінде болған кезде триггер қайта іске қосылса не болатынын шешу қажет:

• жаңа кіруге тыйым салынады
• алдыңғы дана тоқтатылады
• параллель дана жасалады
• қолданыстағы процестің параметрлері жаңартылады
• оқиға еленбейді.

Мұндай ереже болмаса, бір клиент бір автоматтандырудың бірнеше көшірмесіне қатар түсіп қалуы мүмкін.

8. Күту, бақылау нүктелері және сценарийден шығу

CRM-сценарийде жиі күту кезеңдері болады:

• тіркелгеннен кейін 24 сағат күту
• үш күннен кейін сатып алуды тексеру
• бір аптадан кейін екінші хабарламаны жіберу
• тауардың болжамды аяқталу уақытын күту.

Бірақ күту клиент бұрынғы күйінде қалады дегенді білдірмейді.

Үзіліс кезінде ол:

• сатып алу жасауы
• коммуникациялардан бас тартуы
• байланыс деректерін өзгертуі
• басқа санатқа өтуі
• басқа сценарийден хабарлама алуы
• сервистік мәселеге тап болуы
• таңдалған арна үшін қолжетімсіз болуы мүмкін.

Сондықтан күткеннен кейін маңызды шарттарды қайта тексеру қажет.

Bloomreach-тің ресми ұсынымдарында да wait-торабынан кейін маңызды шарттарды қайта тексеру керегі айтылады, себебі клиент деректері өзгеруі мүмкін. Bloomreach: Scenario best practices

Шығу шарттары

Сценарий мына жағдайларда тоқтауы тиіс:

• мақсатты әрекетке қол жеткізілді
• клиент аудиторияға енді сәйкес келмейді
• келісім қайтарып алынды
• ұсыныстың өзектілік мерзімі аяқталды
• тауар қолжетімсіз
• маңыздырақ процесс пайда болды
• сценарийде болудың ең көп уақыты асты
• қауіпсіз жалғастыруға мүмкіндік бермейтін техникалық қате анықталды.

Екінші сатып алу сценарийі үшін негізгі шығу шарты — екінші аяқталған тапсырыстың пайда болуы.

Бірақ бұл шартты тек соңғы хабарлама алдында тексеру жеткіліксіз. Оны сатып алудан кейін мағынасы жоғалатын әр әрекеттің алдында қайталау керек.

9. CRM-сценарийді ассортимент матрицасымен байланыстыру

Жүйе клиентке коммуникация қажет екенін анықтағаннан кейін келесі сұрақ туындайды:

Оған нақты не ұсыну керек?

«Тағы бір сатып алу жасаңыз» деген жалпы шақыру сирек жағдайда ең жақсы шешім болады. Келесі әрекеттің ең өзекті бағытын анықтау қажет.

Ол үшін клиент тарихы ассортимент матрицасымен салыстырылады.

Не ескерілуі мүмкін

• бірінші сатып алудағы тауар
• санат және ішкі санат
• бренд
• тауар мақсаты
• орташа пайдалану мерзімі
• баға
• қолжетімділік
• жаңалықтарға жатуы
• бұрын сатып алынған тауарлармен үйлесімділік
• сатып алудың әдеттегі тізбектері
• бірге жиі сатып алынатын тауарлар
• клиент тарихында әлі жоқ санаттар
• шектеулер мен ерекшеліктер.

Ықтимал механикалар

Қайта сатып алу

Шығындалатын тауарлар үшін, болжамды аяқталу уақыты жақындағанда қолайлы.

Санатты тереңдету

Клиентке өзі таныс санат ішіндегі қосымша өнім ұсынылады.

Санатты кеңейту

Жүйе бірінші сатып алуды қисынды толықтыратын көршілес санатты таңдайды.

Өнім жүйесін жалғастыру

Келесі тауар тек статистикамен емес, өнімдерді пайдалану логикасымен де анықталады.

Жаңа өніммен таныстыру

Жаңа тауар тиісті санатқа қызығушылық танытқан клиенттерге ұсынылады.

Келесі үздік ұсыныс

Тауар немесе санат ережелер жиыны не болжамдық модель негізінде таңдалады.

Детерминделген және болжамдық шешімдер

Екі тәсілді араластырмау маңызды.

Детерминделген логика алдын ала келісілген ережелерге негізделеді:

Егер бірінші сатып алу A санатына жатса, B санатын ұсыну; егер B бұрын сатып алынған болса — C санатына өту.

Мұндай шешім ашық, қайталанатын және бизнесте сараптамалық ережелер бар кезде жақсы жұмыс істейді.

Болжамдық модель тарихи деректер негізінде реакция ықтималдығын бағалайды. Ол тауарларды немесе клиенттерді ранжирлеуі мүмкін, бірақ сапалы тарихтың жеткілікті көлемін және модель сапасын міндетті тексеруді талап етеді.

Bloomreach каталогтар, дербестендіру, ұсынымдық модельдер және клиенттердің болжамдық сипаттамаларын ұсынады. Бірақ мұндай құралдың болуы жүйе дұрыс бизнес-стратегияны автоматты түрде біледі дегенді білдірмейді. Модель өзекті деректерде оқытылып, нәтижесі эксперимент арқылы тексерілуі тиіс. Bloomreach: Personalization, Bloomreach: Predictions

Тәжірибеде жиі гибрид тәсіл қолданылады:

1. Бизнес рұқсат етілген санаттар мен шектеулерді белгілейді.
2. Жүйе бұрын сатып алынған, қолжетімсіз немесе сәйкес емес тауарларды алып тастайды.
3. Қалған жиында тауарлар ережелер немесе модель бойынша ранжирленеді.
4. Таңдалған ұсыныс коммуникацияға беріледі.
5. Нәтиже тіркеліп, кейінгі бағалауда пайдаланылады.

10. Дербестендіру басқарылатын логика ретінде

Дербестендіру — тек клиентке атымен жүгіну емес.

Ол мыналарды анықтай алады:

• хабарлама мазмұнын
• суретті
• өнімді
• санатты
• тілді
• бағаны
• сілтемені
• әрекетке шақыруды
• блоктар ретін
• арнаны
• жіберу уақытын.

Бірақ әр айнымалы ықтимал комбинациялар санын және қате қаупін арттырады.

Егер хабарлама:

• үш елге
• екі тілге
• төрт клиент сегментіне
• бес тауар санатына
• екі арнаға

байланысты болса, қазірдің өзінде 240 ықтимал конфигурация пайда болады.

Сондықтан дербестендіру үшін мыналарды анықтау қажет:

• әр мәннің дереккөзін
• таңдау ережелерін
• рұқсат етілген форматты
• әдепкі мәнді
• деректер болмағанда не істеуді
• ұзындық шектеулерін
• бірнеше нұсқаның басымдығын
• тесттік конфигурацияларды.

Әдепкі мәндер

Жүйе таңдаулы санатты анықтай алмаса, хабарламада бос блок немесе техникалық айнымалы пайда болмауы тиіс.

Әр динамикалық элемент үшін fallback беріледі:

• әмбебап ұсыныс
• танымал санат
• редакциялық блок
• клиентті жіберілімнен шығару
• бөлек тармаққа ауыстыру.

Таңдау тәуекелге байланысты. Кейде жоқ деректі кездейсоқ ұсыныспен алмастырғаннан гөрі коммуникацияны мүлдем жібермеген қауіпсіз.

11. Арнаны таңдау

Email, SMS, push, Telegram, in-app және web layer әртүрлі міндет атқарады.

Арна мыналарды ескере отырып таңдалады:

• келісім
• байланыс деректерінің болуы
• реакция жылдамдығы
• құны
• хабарлама түрі
• жеткізу тарихы
• клиент қалауы
• шұғылдық
• контент көлемі
• қажетті интерфейске тікелей өту мүмкіндігі.

Мысалы:

• email егжей-тегжейлі ұсынысқа қолайлы
• push қысқа әрі уақытылы еске салуға қолайлы
• web layer сайтқа кірген кездегі реакцияға қолайлы
• SMS шұғыл әрі қысқа коммуникацияға қолайлы
• Telegram қосымша қосылған арна ретінде қолданылуы мүмкін
• webhook шешімді сыртқы жүйеге беру үшін қолданылады.

Негізгі және резервтік арна

Омниканалды сценарий бір хабарламаны барлық арнаға бірден жіберу дегенді білдірмейді.

Мынадай реттілік болуы мүмкін:

1. Email жіберу.
2. Жеткізуді немесе реакцияны тексеру.
3. Нәтиже болмаса және келісім бар болса, push пайдалану.
4. Мақсатқа жеткенде барлық кейінгі әрекеттерді тоқтату.

Бірақ fallback бір хабарламаны барлық жерде қайталай бермей, бизнес-мағынаға негізделуі тиіс. Байланыс құнын, шұғылдықты және шамадан тыс қысым қаупін ескеру қажет.

12. Бірнеше сценарийді оркестрациялау

Компанияда бірнеше автоматтандыру жұмыс істегенде, олар бір клиент үшін бәсекелесе бастайды.

Бір уақытта клиент:

• екінші сатып алуды күтуі
• кету белгілерін көрсетуі
• жаңа санатқа қызығуы
• промоға қатысуы
• аяқталмаған себеті болуы
• сервистік хабарламаны күтуі
• бағдарлама шарттарының өзгеруін алуы мүмкін.

Егер әр сценарий тәуелсіз жұмыс істесе, клиент бірнеше қарама-қайшы хабарлама алуы мүмкін.

Мысалы:

• сатып алудан кейін бірден «Сізді сағындық» хабарламасы
• тауарды толық бағамен сатып алғаннан кейін жеңілдік ұсынысы
• бір күнде бес хабарлама
• әртүрлі санаттарды бір уақытта ілгерілету
• маңызды сервистік хабарламаның үстінен маркетингтік хабарлама жіберу.

Сондықтан автоматтандыруға бөлек оркестрация қабаты қажет.

Сценарийлер реестрі

Әр сценарий үшін мыналар тіркеледі:

• мақсат
• аудитория
• триггер
• арна
• әрекет ету кезеңі
• басымдық
• жиілік тобы
• кіру шарттары
• шығу шарттары
• қайшы сценарийлер
• рұқсат етілген комбинациялар
• иесі
• мәртебесі
• нұсқасы.

Басымдық иерархиясы

Мысалы:

1. Критикалық сервистік хабарламалар.
2. Транзакциялық хабарламалар.
3. Клиенттің ағымдағы әрекетіне байланысты сценарийлер.
4. Сатып алуды дамыту сценарийлері.
5. Промо.
6. Қайта белсендіру.
7. Жалпы ақпараттық хабарламалар.

Нақты иерархия бизнеске байланысты. Ең бастысы — ол бүкіл жүйе үшін ортақ болуы керек.

Басу ережелері

Жүйе коммуникацияға тыйым салуы немесе кейінге қалдыруы мүмкін, егер:

• жақында сатып алу болса
• клиент сервистік хабарлама алып жатса
• маңыздырақ сценарий іске қосылса
• клиент сол санат бойынша ұсыныс алып қойған болса
• ең төменгі интервал сақталмаса
• жалпы байланыс лимитіне жетсе.

Жиілік саясаты

Жиілік шектеуі белгілі бір кезеңде клиент қанша хабарлама ала алатынын анықтайды.

Bloomreach коммуникациялар санын шектеу үшін frequency policy орнатуға мүмкіндік береді. Платформа нақты жіберілімдер үшін осындай саясатты пайдалануды және жиілікті шексіз қалдырмауды ұсынады. Bloomreach: Frequency policy, Bloomreach: Scenario best practices

Бірақ жиілік саясаты оркестрацияны алмастырмайды.

Ол күн ішіндегі төртінші хабарламаны бұғаттай алады, бірақ төрт хабарламаның қайсысы ең маңызды екенін өздігінен анықтамайды. Басымдықтар мен қайшылықтар бөлек жобалануы тиіс.

13. Техникалық тапсырма қалыптастыру

Бизнес-логика келісілгеннен кейін CRM-сценарийге техникалық тапсырма жасалады.

Ол басқа маманға автордың ауызша түсіндірмесінсіз алгоритмді түсінуге, іске асыруға және тексеруге мүмкіндік беруі тиіс.

Сценарий паспорты

Құрамында:

• атауы
• бизнес-міндет
• негізгі мақсат
• иесі
• елдер мен тілдер
• жұмыс кезеңі
• арналар
• басымдық
• байланысты сценарийлер болады.

Аудитория сипаттамасы

Мыналарды бекітеді:

• кіру шарттары
• ерекшеліктер
• қайта кіру ережелері
• шектеулер
• аудиторияның есептік көлемі
• қажетті келісімдер.

Триггер

Мыналар сипатталады:

• оқиға немесе кесте
• міндетті параметрлер
• кідіріс
• өңдеу кезеңі
• қайталама сигнал кезіндегі әрекеттер.

Логикалық схема

Әр қадам үшін:

• тексерілетін шарт
• оң тармақ
• теріс тармақ
• әрекет
• күту кезеңі
• қайта тексеру
• шығу шарты көрсетіледі.

Деректерге қойылатын талаптар

Әр өріс үшін:

• техникалық атауы
• сипаттамасы
• дереккөзі
• түрі
• рұқсат етілген мәндер
• есептеу ережесі
• жаңарту кезеңі
• әдепкі мән
• маңыздылығы тіркеледі.

Ассортименттік логика

Мыналар сипатталады:

• кіріс санаттары
• рұқсат етілген ұсынымдар
• ерекшеліктер
• басымдықтар
• қолжетімділік
• алмастыру ережелері
• fallback.

Коммуникациялық талаптар

Құрамында:

• шаблондар
• айнымалылар
• тілдер
• динамикалық блоктар
• сілтемелер
• бақылау параметрлері
• арна
• жіберуші
• жиілік саясаты болады.

Өлшеу жоспары

Іске қоспас бұрын мыналарды анықтау қажет:

• мақсатты оқиға
• конверсия кезеңі
• тесттік және бақылау топтары
• берілетін кампания идентификаторлары
• көрсеткіштер
• нәтижені есептеу әдісі.

Қабылдау критерийлері

Сценарий дайын деп есептелуі мүмкін, егер:

• аудитория анықтамаға сәйкес келсе
• триггер күтілетін сәтте іске қосылса
• барлық тармақ жұмыс істесе
• деректер дұрыс қойылса
• қайта кіру бақыланса
• клиент мақсатты әрекеттен кейін шықса
• келісімдер мен шектеулер сақталса
• кампания оқиғалары тіркелсе
• нәтижелер талдауға қолжетімді болса.

14. CRM-платформада техникалық іске асыру

ТТ бекітілгеннен кейін логика бағдарламалық қамтамасыз етуге көшіріледі.

Bloomreach Engagement-те бұл үшін мыналар қолданылуы мүмкін:

• оқиғалар және клиент қасиеттері
• агрегаттар
• сегментациялар
• өрнектер
• каталогтар
• триггерлер
• шарттар
• wait-тораптар
• A/B-бөлу
• email, SMS, push, web layers және басқа әрекеттер
• webhooks
• атрибуттарды өзгерту
• техникалық оқиғаларды жазу
• Jinja көмегімен динамикалық дербестендіру.

Визуалды Scenario Builder триггерлерді, шарттарды, күтулер мен әрекеттерді орындалатын ағынға біріктіруге мүмкіндік береді. Bloomreach: Scenario building and editing

Бірақ визуалды схема — тек іске асыру тәсілі. Автоматтандыру сапасы тораптар санына емес, мыналардың қаншалықты дәл формалданғанына байланысты:

• деректер
• бизнес-мағына
• шарттар
• ауысулар
• ерекшеліктер
• басымдықтар
• нәтижені бақылау.

Күрделі сценарий міндетті түрде жақсы сценарий емес. Бір міндетті он тораппен сенімді шешуге болса, елу тораптан тұратын схема тек тестілеу мен сүйемелдеуді қиындатады.

15. Сценарийді тестілеу

CRM-сценарийді бір тесттік хат жіберумен ғана тексеруге болмайды.

Бүкіл алгоритмді тестілеу қажет.

Оң тексерулер

Сәйкес клиенттің:

• сценарийге кіретінін
• дұрыс тармаққа түсетінін
• қажетті контент алатынын
• аналитикада ескерілетінін
• мақсатты әрекеттен кейін шығатынын растайды.

Теріс тексерулер

Сәйкес емес клиенттің:

• келісімсіз кірмейтінін
• екінші сатып алудан кейін шығарылатынын
• тауар болмағанда хабарлама алмайтынын
• тапсырыс мәртебесі қате болғанда өтпейтінін
• лимиттен артық қайталама хабарлама алмайтынын растайды.

Шекаралық шарттар

Қателер жиі пайда болатын сәттер тексеріледі:

• сатып алудан кейін дәл 14 күн
• тексеруге бір секунд қалғанда сатып алу
• уақыт белдеуінің өзгеруі
• толық қайтару
• бір уақытта жасалған екі сатып алу
• бос санат
• белгісіз тіл
• қайталама оқиға
• күту кезіндегі келісімнің өзгеруі.

Дербестендіруді тексеру

Әр маңызды конфигурация үшін мыналар тексеріледі:

• тіл
• ел
• сегмент
• санат
• баға
• сілтеме
• сурет
• fallback
• мәтінде техникалық мәндердің болмауы.

Басқа сценарийлермен үйлесімділікті тексеру

Мыналарға көз жеткізу керек:

• басымдықтар жұмыс істейді
• жиілік шектеулері қолданылады
• қайшы сценарийлер басылады
• сервистік коммуникациялар маркетингтік хабарламалармен бұғатталмайды
• клиент қайталама ұсыныс алмайды.

Bloomreach алдын ала қарау, тесттік оқиғалар және нақты орындалуды имитациялайтын режим арқылы тестілеуді қарастырады. Bloomreach: How to test scenarios

16. Бақыланатын іске қосу

Тестілеуден кейін сценарийді бірден бүкіл аудиторияға іске қосу міндетті емес.

Мынадай нұсқалар болуы мүмкін:

• ішкі профильдерде іске қосу
• шектеулі пилот
• аудиторияның шағын үлесіне іске қосу
• бір елде немесе бір тілде іске қосу
• көлемді біртіндеп арттыру
• бақылау тобын қатар сақтау.

Масштабтауға дейін мыналар тексеріледі:

• кірген клиенттер саны
• тармақтар бойынша үлестірім
• шығарылғандардың үлесі
• айнымалы қою қателері
• жеткізу
• жиілік бұғаттаулары
• мақсатты оқиғаларға жету
• интеграцияларға түсетін жүктеме
• нақты көлемдердің болжамға сәйкестігі.

Егер есептік аудитория 20 000 адам болса, бірақ сценарийге 200 000 кірсе, жіберілімді тоқтатып, шарттарды тексеру қажет. Мұндай күрт айырмашылық деректердегі, аудитория анықтамасындағы немесе қайта кіру логикасындағы қатені дерлік әрқашан көрсетеді.

17. Мониторинг және дамыту

Іске қосылғаннан кейін сценарий жұмыс істейтін ақпараттық жүйенің бір бөлігіне айналып, сүйемелдеуді қажет етеді.

Мыналарды бақылау керек:

• деректердің түсуін
• триггерлер тұрақтылығын
• клиенттер үлестірімін
• техникалық қателерді
• айнымалылардың толтырылуын
• басылған жіберілімдер санын
• қайта кіру жиілігін
• әрекеттердің сәттілігін
• сегмент көлемдерінің өзгеруін
• тауарлардың қолжетімділігін
• сценарий нәтижелілігін.

Неліктен логика уақыт өте ескіреді

Мыналар өзгеруі мүмкін:

• ассортимент
• пайдалану мерзімдері
• адалдық бағдарламасы
• бизнес-ережелер
• деректер моделі
• API
• каталог құрылымы
• клиенттердің мінез-құлқы
• келісімдерге қойылатын талаптар
• елдер мен тілдер тізімі
• сценарийлер арасындағы қатынастар.

Сондықтан автоматтандырудың иесі, құжаттамасы және өзгерістер тарихы болуы тиіс.

Өзгеріс енгізгенде мыналарды түсіну маңызды:

• қандай гипотеза тексеріледі
• логиканың қай бөлігі өзгерді
• жаңа нұсқа қашан күшіне енді
• қандай көрсеткіштер салыстырылады
• өзгеріс басқа сценарийлерге қалай әсер етеді.

Осылайша жүйе басқарылатын түрде дамып, кім және қашан жасағаны белгісіз схемалар жиынтығына айналмайды.

CRM-автоматтандырудағы типтік қателер

Логикадан емес, хабарламадан бастау

Команда аудитория, мақсат, триггер және шығу шарттары анықталмай тұрып хат тақырыбын талқылайды.

Дәл емес оқиғаларды пайдалану

Мысалы, тапсырыстардың едәуір бөлігі тоқтатылса да, жасалған тапсырысты сатып алу деп санау.

Күтуден кейін шарттарды қайта тексермеу

Клиент сатып алып қойған, бірақ еске салуларды ала береді.

Қайта кіруді анықтамау

Бір адам бір сценарийдің бірнеше данасына түседі.

Күй мен сегментті араластыру

Клиентке өмірлік циклді, қызығушылықты, тәуекелді және арналардың қолжетімділігін бір уақытта сипаттауға тырысатын бір мәртебе беріледі.

Сенімсіз деректер бойынша дербестендіру

Коммуникацияға бос санаттар, ескірген бағалар және қате тіл түседі.

Жеткілікті негізсіз AI пайдалану

Сапалы тарих, нақты мақсат немесе нәтижені тексеру мүмкіндігі жоқ жерде болжамдық модель қолданылады.

Басқа кампанияларды ескермеу

Әр сценарий жеке дұрыс жұмыс істейді, бірақ бірге олар шамадан тыс және қарама-қайшы қысым жасайды.

Тек ашулар мен өтулерді бағалау

Арнаның техникалық көрсеткіштері мақсатты бизнес-әрекетті алмастырады.

Жүйені құжаттамау

Автор кеткеннен кейін дәл осындай интервалдар, сүзгілер мен ерекшеліктер неге таңдалғанын ешкім түсінбейді.

Бізге қандай міндеттермен жүгінуге болады

Бізге мынадай жағдайда жүгінуге болады:

• клиенттің өмірлік цикл моделін құру
• CRM-сценарийлер жүйесін анықтау
• бизнес-міндеттерді техникалық логикаға аудару
• кіру, шығу және ауысу шарттарын жобалау
• бірінші, екінші және кейінгі сатып алуларды автоматтандыру
• cross-sell және санаттарды дамыту сценарийлерін әзірлеу
• CRM-ді ассортимент матрицасымен байланыстыру
• қайта белсендіру мен кетуді болдырмауды баптау
• коммуникацияларды басымдыққа бөлу ережелерін әзірлеу
• кампаниялар арасындағы қайшылықтарды жою
• жиілік шектеулерін енгізу
• техникалық тапсырмалар қалыптастыру
• Bloomreach Engagement-те сценарийлерді баптау
• қосымша арналарды қосу
• жұмыс істеп тұрған автоматтандыруларды тексеру
• тестілеу және мониторинг жүйесін әзірлеу
• аналитика негізінде сценарийлерді өзгерту қажет болса.

Біз бүкіл жүйені жобалауға да, жеке кезеңге де қосыла аламыз: әдістеме әзірлеу, техникалық тапсырма дайындау, CRM-платформаны баптау, тестілеу, іске қосу немесе сүйемелдеу.

Бизнес не алады

Жұмыстың нәтижесі жеке кампания емес, басқарылатын CRM-автоматтандыру жүйесі болады:

• формалданған өмірлік цикл моделі
• клиент ауысуларының картасы
• сценарийлер реестрі
• келісілген кіру және шығу ережелері
• басымдықтар мен шектеулер жүйесі
• ассортимент матрицасымен байланыс
• техникалық тапсырмалар
• бапталған автоматтандырулар
• тесттік сценарийлер
• мониторинг жүйесі
• кейінгі дамытуға арналған құжаттама.

Мұндай жүйе компанияға клиенттік тәжірибені дәйекті басқаруға көмектеседі: адамды тіркелуден бірінші сатып алуға дейін сүйемелдеу, қайталама сатып алуларды дамыту, ассортиментті пайдалануды кеңейту, белсенділіктің төмендеуін анықтау және өзекті әрекетті уақтылы іске қосу.

Автоматтандырудың негізгі құндылығы CRM-нің адам қатысуынсыз хабарлама жібере алуында емес.

Оның құндылығы бизнес-логиканың формалданған, орындалатын және өлшенетін болуында. Жүйе деректерді алады, клиент күйін түсіндіреді, рұқсат етілген әрекетті таңдайды, нәтижені тіркейді және жаңа оқиғаларды келесі шешім үшін пайдаланады.