Шартты мысал: сайт «өтінім жіберілді» деді, бірақ CRM ішінде ол жоқ. Менеджер мәселені клиент қайта қоңырау шалғанда біледі. Сайттағы жасыл батырма осы уақыт бойы өзін керемет сезініп тұрды.
Интеграцияны қосу — пайдаланудың басы. Бизнес үшін деректі бір рет жіберу ғана емес, ақауды байқап, өтінішті жұмысқа қайтару жолын түсіну маңызды.
Бірінші тексеру: қажетті жерге жетті ме?
Интеграция — мысалы, сайт пен CRM арасындағы алмасу. Жіберушіге сәтті жауап қайтуы бизнес үдерістің аяқталғанын әрдайым дәлелдемейді.
Оқу өтінімінде бүкіл тізбекті тексеріңіз: сұрауды қабылдау, қажетті жазбаны жасау, жауаптыны тағайындау және келесі әрекеттің пайда болуы. Өтінімді екі жүйеден де табудың түсінікті тәсілін сақтаңыз.
CRM-ге дейін аралық сервис болса, оның «сәтті» мәртебесі нені білдіретінін анықтаңыз: деректі қабылдады ма, әлде әрі қарай жеткізді ме?
Екінші тексеру: мазмұн белгішеден маңызды
Атын, байланыс тәсілін, тауарын, санын және сценарийге қажет басқа өрістерді салыстырыңыз. Бос өріс кейде анық қатеден қауіпті: карточка бар, бірақ оны өңдеу мүмкін емес.
Қырғызстандағы компания оқу үлгісіне қолданылатын тілдерді, телефон пішімдерін және құрылу уақытын қосқаны пайдалы. Сынақ үшін нақты тапсырыстарды өзгертпеңіз.
Қай айырмашылық маңызды және оны кім тексеретінін келісіңіз. Клиенттің өзі алмасуға аудит жүргізгенін күтудің қажеті жоқ.
Үшінші тексеру: қайталау және белгісіз нәтиже
Бір оқиға қайталанып келуі мүмкін. Өңдеуші әр жолы тексермей жаңа сату жасаса, байланысты түзету дубльдер тудыруы ықтимал.
Жобада өңделген оқиғаны тану және нәтижемен байланыстыру тәсілі болуы керек. Нақты тәсіл интеграцияға байланысты; әмбебап батырмаға уәде бермеңіз.
Өзгерістің аяқталғаны белгісіз тайм-аут кезінде алдымен қабылдаушы жүйені тексереді. Соқыр қайта жіберу екінші жазба жасауы мүмкін. Бұл жағдайды келісілген сынақтарға міндетті түрде қосыңыз.
Төртінші тексеру: қатені кім біледі?
Қате журналы — ненің өтпегенін және неге өтпегенін түсіндіретін оқиғалар тізімі. Басшыға барлық техникалық жол емес, жауапты, өңделмеген оқиғалар саны және қалпына келтіру тәртібі маңызды.
Битрикс24 REST API ішінде жүктеме шектеулері мен лимит қателері бар — олар ресми құжаттамада сипатталған. Өңдеу сұрауларды шексіз қайталамай, өнім ұсынымдарын ескеруі керек.
Рұқсат етілген кідірісті, хабарлама алушысын және қауіпсіз қайта іске қосу жолын келісіңіз. Құпиясөздер мен кілттер бүкіл команда көретін журналға түспеуі тиіс.
Бесінші тексеру: қалпына келтіру шынымен істей ме?
Рұқсат етілген сынақ сценарийінде қабылдаушының уақытша қолжетімсіздігін, байланыстың қалпына келуін және жиналған оқиғалардың өңделуін тексеріңіз. Нәтижені бастапқы өтінімдермен салыстырыңыз: не қабылданды, не өңделді және не қатемен қалды?
Қызметкердің әдеттегі әрекеттерін және маман керек болатын сәтті сипаттаңыз. Жүйе жаңарғаннан немесе өрістер өзгергеннен кейінгі тексеруге иесін белгілеңіз. Әйтпесе кеше жұмыс істеген алмасу бүгін маңызды бір мәнді үнсіз жоғалтады.
QQDev API арқылы алмасуды, оның ішінде қайталауларды өңдеуді, қате журналын және құжаттаманы әзірлейді. Интеграция әзірлеу бетінде тізбегіңізді тексеруді талқылауға болады. Жеке дерексіз бір мысал әкеліп, команда қазір жоғалған өтінімді қалай білетінін түсіндіріңіз.