CRM-ды телефониямен біріктіру: карточкалар, тегтер, жазбалар

CRM, телефония және қоңырау жазбаларын неге байланыстыру керек

CRM-ды телефониямен біріктіру «көрікті панель» үшін емес, әрбір қоңырау автоматты түрде клиентпен жұмыс тарихының бір бөлігі болуы үшін қажет. Телефон, клиенттің карточкасы және жазба бөлек жүрсе, қызметкерлер іздеуге уақыт жұмсайды, жазбаларды қолмен толтырады және детальдарды жоғалтады. Соның нәтижесінде сервис сапасы төмендейді, даулы жағдайларды шешу ұзақ әрі ауыр болады.

CRM + телефония + қоңырау жазбалары әдетте төрт мәселені шешеді.

Біріншісі — телефон көтерілгенге дейін контекст: кім қоңырау шалып тұр, бұрын қандай байланыстар болған, қандай келісімдер бар.

Екіншісі — байланыс фактінің тіркелуі: қоңырау автоматты түрде мәмілеге, өтінішке, пациентке немесе контрагентке байланады.

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

Төртіншісі — сәйкестік (комплаенс): жазбалар келісімдерді растауға және ішкі регламенттерді сақтауға көмектеседі.

Бұл әсіресе қателік құны жоғары жерлерде маңызды: сату бөлімінде (жедел әрекет пен мәміле тәртібі), қолдауда (қайталанатын өтініштер және бір стандартты жауап), төлем жинауда (байланыстардың дәлелдігі), тіркеу бөлімінде және колл-орталықтарда (жазбаның дәлдігі, «жоғалған» қоңыраулардың болмауы).

Тақырыптың бөлек жағы — жабық контур. Бұл жерде деректер мен сервистер қоғамдық бұлтқа шықпайды: жазбалар, қоңырау метадеректері және оларға қолжетімділік ұйым шеңберінде (мысалы, локалдық дата-орталықта) қалады. Мұндай тәсіл архитектураға бірден әсер етеді. Алдын ала жазбалар қайда сақталатынын, кім және қалай тыңдайтынын, файлдар қанша уақыт сақталатынын және құқықтар қалай орнатылатынын шешу керек, сонда «бәрін көру» тек шынымен қажет адамдарға ғана қолжетімді болады.

Шешімнің құрамдас бөліктері: терминдер қарапайым тілде

CRM мен телефонияны біріктіру күрделі көрінгенімен, негізінен үш блоктан тұрады, олар түсінікті оқиғалармен (кім, кімге, қашан және не болғаны) алмасады.

CRM — деректер мен жұмыс ережелері сақталатын орын. Мұнда контактілер мен компаниялар, мәмілелер, қолдау өтініштері және пайдаланушы ролдері (мысалы, колл-орталық операторы бір нәрсені көреді, ал басшы басқа нәрсені) сақталады. CRM нақты қоңырауды қай объектіге байлауды және қай жерде байланыс тарихын көрсету керектігін шешеді.

Телефония — қоңырауларды қабылдап, бағыттайтын жүйе. Көбіне SIP протоколы, ішкі нөмірлер, очередтер (қоңырау бос операторды күту үшін) және IVR (дауыстық мәзір) қолданылады. Мұнда сценарийлер: қоңырауды кімге жіберу, егер барлығы бос болмаса не істеу, бірінші жауап беруші кім, жұмыс уақытынан тыс қалай әрекет ету — бәрі анықталады.

Қоңырау жазбалары — бөлек контур, оны алдын-ала ойластырған жөн. Әдетте шешімдер үш сұраққа түседі: жазба қай жерде қосылады (АТС-та немесе жазба сервисінде), кімде қолжетімділік бар (ролдер бойынша және әрекеттер журналы), және жазба қалай ізделеді (нөмір, дата, қызметкер, мәміле, тег бойынша).

Қоңырау оқиғалары — жүйелер не болып жатқанын түсіну үшін жіберілетін «сигналдар». Көбіне кіріс және шығыс қоңырау, басқа қызметкерге аудару, күту (клиент күтіп тұрған кезде), қоңыраудың аяқталуы және жалпы ұзақтығы талап етіледі.

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

Интеграция типтік схемалары және жабық контурға сәйкес келетіндері

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

Ең жиі кездесетін нұсқалар:

1) Бұлттық телефония + бұлттық CRM. Жылдам іске қосылады, бірақ жабық контур үшін көбіне жарамайды: қоңырау метадеректері мен жазбалар сыртқа шығады, бұл көп жағдайда тыйым салынған.

2) Локальды АТС + контур ішіндегі CRM. Мемлекеттік ұйымдар мен қаржы секторына тән таңдау: қоңырау, карточка және жазба желінің ішінде қалады, сақтау және қолжетімділіктер бойынша талаптарды орындау оңайырақ.

3) Гибрид. Нөмірлер мен маршрутизация үшін оператор немесе бұлттық телефония пайдаланылады, бірақ интеграциялық шлюз пен жазбалар хранилищасы локальды болады. Мұны сол кезде қолданады, егер телефония сыртқа өтуі мүмкін, ал деректер мен аудио іште қалуы тиіс болса.

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

Шектеулерді тексеріңіз: желінің сегментациясы және сайттар арасында VPN, шығатын қосылыстарға қатысты ережелер, сыртқы API-лар қолжетімділігі (түзу, прокси арқылы, ақ тізіммен), сақтау мерзімдері мен шифрлау талаптары, қолжетімділер журналының қажеттілігі. Инфрақұрылымды бөлек бағалаңыз: хранилище қайда болады (NAS/SAN/сервер), резерв және геокөшірме керек пе, және 24/7 режимінде кім әкімшілік етеді.

Қоңырауда пайда болатын карточкалардың сценарийлері: не көрсету және кімге көрсету керек

Пайда болатын карточка қызметкерге сөйлесу қалай бастау керектігін түсіндіру үшін қажет. Сондықтан маңызды екеу: клиентті қалай табасыз (іздеу) және карточканы кімге көрсетесіз (құқықтар мен көрсету логикасы).

Ең кең тараған іздеу — телефон нөмірі бойынша. Бұл жылдам, бірақ дубльдер мен жалпы нөмірлерден қателіктер туғызуы мүмкін. Бір мобильді бірнеше уақытта Контактқа, Контрагентке немесе миграциядан кейінгі «ескі» жазбаға тіркелген болуы ықтимал. Мұндай кезде қысқа сәйкестіктер тізімін көрсету және «дубликаттар бар, жазбаны таңдаңыз» деген ескерту ұсыну, сондай-ақ мұндай жағдайларды кім түзететіні және қандай мерзімде екенін ереже ретінде бекіту пайдалы.

Егер қоңырау компанияның жалпы нөміріне (ресепшен, колл-орталық) келсе, карточканы бәріне көрсету дұрыс емес. Практикалық шешім — карточканы контрагенттің карточкасына және жауапты адамға байлау: қоңырауды клиентке жауапты адам көреді, резервті түрде — топ (дежурная смена). Бұл клиент деректерін артық адамдардың қарауынан сақтайды.

Тиімді сценарий — соңғы белсенділік бойынша іздеу. Ол бір клиент әртүрлі бөлімдермен байланысқанда көмектеседі: кеше қолдау жазған болса, бүгін сату бөліміне қоңырау шалып жатса карточка бірден «соңғы байланыс — қолдау, статус: жұмыс істеп жатыр» деген контекст береді.

Экранда алғашқы 3 секундта тек ең қажетті ақпарат болу керек: атауы немесе компаниясы, қысқа статус (жаңа, VIP, проблемалық, төлемі кешіктірілген), жауапты және бөлім, ашық тапсырмалар немесе жақын мерзімі бар өтініштер. Қарыз, лимит немесе блоктау сияқты шектеулерді тек сөйлесу үшін шын қажет және қолжетімділік саясатымен рұқсат етілген жағдайда ғана көрсетіңіз. Қалған детальдарды екінші экранға өткізіңіз, әйтпесе карточка тым жүктелген кестеге айналып кетеді.

Қоңырауларды маршрутизациялау логикасы және CRM объектілеріне байлау

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

Кіріс қоңырауда әдетте алдымен нөмір CRM-де ізделеді. Клиент табылса, операторға контекст көрсетіледі: аты, компаниясы, активті мәміле немесе өтініш, соңғы байланыс. Жақын жерде қысқа скрипт пен жылдам әрекеттер пайдалы: мәмілені ашу, өтініш жасау, тапсырма қою.

Тарату ережелерін қарапайым ұстаңыз. Мысалы: бекітілген менеджер бар болса — қоңырау соған; ол бос емес болса — топтың очередьіне; жарнама бойынша — кампанияға байлап, қажетті очередь-ге жіберу; қолдау — тақырып немесе өнім бойынша (1-ші линия, 2-ші линия); VIP немесе SLA бойынша — приоритет қою; жаңа нөмір — лид құрып, жалпы пулға жіберу.

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

Аударулар мен консультациялар жауапкершілік үшін маңызды. CRM қатысушылардың тізбегін сақтауы тиіс: кім қабылдады, кім кеңес берді, кімге тапсырды және бұл қандай объектіге қатысты.

Пропущенный қоңырау «жоғалмауы» керек. Жақсы баптау автоматты түрде перезвон үшін тапсырма жасайды және SLA бойынша (мысалы, 15 минут) дедлайн мен жауапты тағайындайды.

Мысал: клиент ағымдағы мәміле бойынша қоңырау шалды, менеджер бос емес. Қоңырау очередке кетеді, оператор мәміле карточкасын көріп, белгі қояды, инженерге аударады, ал CRM-де біртұтас тарих сақталады: кіріс, қатысушылар, нәтиже және келесі байланысқа тапсырма.

Қоңырауларға тег қою: ережелер, ролдер және пайдалы есептер

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

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

Әдетте бірнеше категория жеткілікті.

Причина: «шот бойынша сұрақ», «техникалық қолдау», «шағым», «қайталанатын байланыс», «жаңа өтініш».

Нәтиже: «шешілді», «аударылды», «қоңырауға жетпеді», «бас тартты», «кездесу тағайындалды».

Көңіл-күй: «тыныш», «тартыншақ», «қақтығыс».

Келесі қадам: «перезвон жасау», «коммерциялық ұсыныс жіберу», «эскалация», «жабу».

Кімді тег қоятыны процесс бойынша анықталады. Оператор қоңыраудан кейін себеп пен нәтижені белгілейді. Басшы күрделі жағдайларды талдағаннан кейін қосымша белгілер қояды. Сапа бақылауы стандарттар бойынша жеке белгілер қоя алады. Автотұрежелер рутинаны жабады: нөмір бойынша (VIP, жеткізуші), очередь бойынша (сатулар, қолдау), ұзақтығы, күту уақыты немесе пропущенный қоңырау бойынша автоматты түрде тег қоюға болады.

Тегтер «қоқысқа» айналмас үшін ережелер бекітіңіз: бір негізгі себеп тегі, бір нәтиже тегі және максимум 1-2 қосымша.

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

Кішігірім сценарий: клиент бір өтініш бойынша екінші рет қоңырау шалды, 2 минут күтіп, ашуланған. Автотұреже «қайталанатын байланыс» және «ұзақ күту» тегтерін қояды, оператор «шағым» және «эскалация» қосады. Басшы жазбаны ғана емес, түсінікті картинаны көріп, мәселені түзете алады.

Жабық контурда қоңырау жазбаларын сақтау: нұсқалар

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

Көбіне үш нұсқаның бірін таңдайды (кейде біріктіріп): жазбаларды CRM ішінде сақтау, АТС-та сақтау немесе бөлек локальды файл/объектілік хранилищеға шығару.

CRM ішінде іздеуі клиент карточкасы мен мәміле бойынша ыңғайлы, бірақ CRM аудио көлемін көтере ме және құқықтар қалай ұйымдастырылғанын алдын-ала тексеру қажет.

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

Локальды сервердегі бөлек файлдық немесе объектілік хранилище бақылау мен икемділікті береді. Жазбалар жабық желіде қалуы керек болғанда және жүйелер бірнеше болғанда бұл жақсы нұсқа.

Жабық контур үшін қауіпсіздік ережелерін алдын-ала бекітіңіз: оқшауланған желі, ролдер (оператор, басшы, комплаенс), жазбаларды қарау мен жүктеу журналы, рұқсат беру және қайтару процесі.

Сақтау мерзімдерін саясатпен рәсімдеңіз, шығарықтармен ерекшеліктерге рұқсат беріңіз. Мысалы: «қалыпты сатулар — 90 күн, қолдау өтініштері — 180 күн, даулы жағдайлар — шағым жабылғанға + 1 жыл». Солайша артық сақталмай, маңызды нәрсені де жоғалтпайсыз.

Шифрлау мен кілттерді де келісіп қойыңыз. Практикалық минимум: дискіде және тасымалдау кезінде шифрлау, кілттер контур иесінде (подрядчикте емес), кілттерді ротациялау кестесі және кадр өзгерісінде ротация, бэкаптар да сол құқықтармен қорғалсын.

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

Интеграцияны кезең-кезеңімен қалай орнату керек

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

1) Талаптарды бекіту

5-10 нақты сценарий жинаңыз (кіріс, шығыс, аудару, пропущенный, қайталанатын қоңырау), ролдер (оператор, басшы, сапа қызметі), SLA және шектеулер (жазбалар қайда сақталады, қанша күн, кім жүктей алады). Бірден шешіңіз: нөмірлерді маскілеу қажет пе және жазбаға келісімді қалай растайсыз.

2) Справочниктер мен деректер құрылымын дайындау

Есептер жұмыс істеуі үшін бірыңғай статустар мен тегтер туралы келісіңіз. Содан кейін CRM-де қоңырауды қай объектіге байлайтынын анықтаңыз: контактқа, мәмілеға, қолдау өтінішіне немесе бірден бірнеше объектіге.

Кейін қадам бойынша іске кірісіңіз.

1. CRM-де оқиғалар мен өрістерді орнатыңыз: қоңырау идентификаторы, бағыт, ұзақтық, нәтиже, тегтер, жазбаға сілтеме, жауапты.
2. Телефонияны қосыңыз: нөмірлер, очередтер, графиктер, бөлу ережелері, жұмыс орындары және гарнитуралар.
3. Пайда болатын карточкаларды және объектілерді автосоздауды орнатыңыз (лид немесе тикет) анық ережелер бойынша.
4. Қоңырау жазбаларын және қолжетімділіктерді орнатыңыз: кім тыңдайды, кім бағалайды, жазба тек сұраныс бойынша көрінеді ме.
5. Жабық контурда сақтау тексеріңіз: сақтау орны, шифрлау, бэкаптар, аудит журналдары.

3) Пилот пен оқыту

Пилотты кішкентай топпен және нақты кейстермен іске қосыңыз: 1-2 очеред, бірнеше оператор, бір басшы. Типтік қателерді жинаңыз (қоңырау дұрыс объектіге байланбайды, тегтер толтырылмайды, жазба құқық бойынша ашылмайды), ережелерді түзетіп, содан кейін масштабтаңыз. Егер жобаны жүйелік интегратор жүргізіп жатса, алдын-ала қабылдау чек-листі мен жабық контурға арналған тест жоспарын сұраңыз.

Жиі кездесетін қателер және оларды қалай болдырмау керек

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

Қоңырау дұрыс карточканы ашпайды. Көбіне себеп — дубльдер мен нөмір форматы (ел коды бар/жоқ, бос орындар). Бір форматқа келтіру, дедупликация ережесі және іздеу приоритетін орнату (мысалы, алдымен Контакт, кейін Компания, содан соң Мәміле) көмектеседі.

Тегтер «қоқысқа» айналады. Тегтер тым көп болғанда операторлар кездейсоқ таңдайды, басшы есеп құра алмайды. Бастапқыда 6-10 тег және олардың анықтамалары жеткілікті. Міндетті тегтер тізімін кілтті қоңыраулар үшін бекітіңіз.

Жазбалар бәріне ашық және әрекеттер жазылмайды. Жабық контурда бұл комплаенс қатері. Рөлдермен қолжетімділіктер және жазбаларды қарау/жүктеу журналы қажет.

Жазбаларды "қайда попало" сақтап қою. Жұмыс станцияларында, жалпы папкаларда немесе бақыланбаған желілік каталогтарда сақтау — қауіпті. Бір басқарылатын локальды хранилище таңдаңыз, құқықтар мен сақтау мерзімдерін орнатыңыз.

Жүктемені бағаламау. Жазбалар дискіні тез толтырады, бэкап көлемі өседі, іздеу баяулайды. Алдын ала күнделікті қоңыраулар санын, орташа ұзақтығын есептеп, 3-6 айға көлем пен резервті жоспарлаңыз, жою ережелерін орнатуды ұмытпаңыз.

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

Іске қосар алдындағы және кейінгі чек-лист

Барлығын жалпыға қосар алдында тест тобына қысқаша сынақ жасаңыз: 2-3 оператор, 20-30 нақты қоңырау, типтік кейстер (жаңа клиент, қайталанған клиент, аудару, пропущенный). Бұл кезеңде бастысы — әдемілік емес, болжамдылық.

Іске қосар алдында әр кіріс және шығыс қоңыраудың автоматты түрде дұрыс объектіге байланатынын тексеріңіз (бірнеше сәйкестік болғанда не болатыны түсінікті болсын), пайда болатын карточка жылдам ашылып, жұмыс істеу үшін минимум көрсететінін, тегтер қажет жерде міндетті екенін және жазбалар жабық контурда рөлдер бойынша қатаң қолжетімді екенін растап алыңыз. Сондай-ақ мәселе туралы кімге жазу керектігін және нені инцидент санау керектігін анықтаңыз (мысалы, жазба сақталмады, карточка ашылмады, қоңырау байланбады).

Іске қосқаннан кейін жүйенің қазір қалай жұмыс істейтіні ғана емес, бір апта немесе бір ай өткеннен кейін даулы жағдайлардың туындауы мүмкін екенін дәлелдеу мүмкіндігі маңызды. Жазбаларға әрекеттер журналы, сақтау мерзімдері мен жою ережелері, резервтік көшіру (және инструкция бойынша кем дегенде бір қалпына келтіру тесті), апта сайын 10-20 мысалда қоңыраулардың CRM объектілерге дұрыс байлануын тексеру, сондай-ақ ішкі қолдау арнасы және SLA: жауап уақыты, шешім уақыты, интеграция иесі — бәрін бақылаңыз.

Алғашқы 2 аптада 5-7 типтік ақауды жинап, ережелерді бекітсеңіз (привязка, тегтер, ролдер, сақтау), жүйе әдетте жай жұмыс істей бастайды.

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

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

Сату менеджері клиенттің қолдаумен байланысқанын көріп, бірдей сұрақтарды қайталамайды. Егер қоңырау сату туралы болса — сатуларға аударады; егер жеткізу немесе баптау мәселесі болса — қолдауға жібереді. Екі жағдайда да сөйлесу автоматты түрде қажетті CRM объектісіне тіркеледі (мәміле, өтініш, заказ), сонда тарих әр жерге шашылып кетпейді.

Әңгімеден кейін оператор қысқа нәтижелер тізімінен таңдайды: «квалификацияланған», «есеп керек», "бас тартты - баға", "бас тартты - мерзімдер", "инцидент шешілді", "шаруашылыққа шығын керек". Тег негізінде CRM келесі қадамды ұсынады: тапсырма құру, еске салғыш қою, коммерциялық ұсыныс жіберу немесе қолдауға өтініш ашу. Интеграция күнделікті жұмысты және бақылауды жеңілдетеді.

Басшы барлық жазбаларды тыңдамайды. Ол тегтер мен қарапайым ережелер бойынша сұрыптайды: ұзын сөйлесулер, қайталанатын өтініштер, бас тартулар, эскалациялар. Содан кейін карточкадан жазбаны ашады, бірақ тек рұқсат болған жағдайда. Жазбалар жабық контурда сақталады, қолжетімділік ролдер бойынша беріледі: сатушылар өз қоңырауларын көреді, қолдау — өздерінкі, басшылар — команда бойынша таңдауды көре алады.

Айдан соң айқын көрсеткіштер пайда болады: пропущенных қоңыраулар үлесі және олардың қаншасына уақытында перезвон жасалғаны, орташа жауап беру уақыты, жаңа лидтер бойынша бірінші байланысқа кететін уақыт, тегтер бойынша бас тарту себептері, қолдауға арналған қайталанатын өтініштердің үлесі «шешілді» статустан кейін.

Келесі қадамдар: енгізу жоспары және интегратордың көмегі

CRM пен телефония интеграциясы бөлшектелген баптауларға айналмасын десеңіз, алдымен қандай қоңыраулар сізде болатынын және CRM-де не болуы керек екенін нақтылаңыз. Әдетте 5-7 негізгі сценарий жеткілікті: клиенттен кіріс, қайталанған қоңырау, пропущенный, басқа қызметкерге аудару, сайттағы өтініш бойынша қоңырау, қолдау қоңырауы, қарыз бойынша қоңырау.

Содан кейін жоспар бойынша жүріңіз:

• Сценарийлер мен CRM-де қажет өрістерді сипаттау: қандай карточка пайда болады, қандай деректер көрсетіледі, қандай әрекеттер міндетті (лид құру, мәміле ашу, тапсырма қою).
• Тегтеу қалай жұмыс істейтінін шешу: кім тег қояды, қандай тегтер міндетті, қайсысын қоңыраудың нәтижесі санаймыз.
• Жазбаларды жабық контурда сақтау мен қолжетімділікті анықтау: кім тыңдайды, кім жүктейді, қанша уақыт сақтау, келісім мен негіздемені қалай тіркеу.
• Бір топта пилот жоспарлау (мысалы, 5-10 оператор) және табыс критерийлері: тегтер толтырылатын қоңыраулар үлесі, өңдеу жылдамдығы, дау жағдайларының саны.
• Масштабтау дайындығы: ролдер шаблондары, есептер, оқыту, өзгерістерге регламент.

Инфрақұрылымды алдын-ала талқылаңыз. Егер жазбалар локальды түрде сақталуы тиіс болса, серверлер мен аудит талаптарын, бэкапты және қолжетімділік талаптарын нақтылаңыз — пилот көрсеткен нәтижеден кейін келісулерге уақыт үнемдейді.

Егер инфрақұрылымды және жүйелерді периметр ішінде жабатын партнер керек болса, Қазақстанда мұндай тапсырмаларды жиі GSE.kz деңгейіндегі жүйелік интеграторлар орындайды: олар локальды серверлер мен жұмыс станцияларын жеткізіп, контурда шешімдер орнатады және 24/7 эксплуатациясын қамтамасыз етеді, бұл деректер мен қолжетімділік бойынша қатал талаптары бар ұйымдар үшін ыңғайлы.