Интеграция support.belblank.by с Битрикс24 для Белбланкавыд

<h2 class="standart_h2 standart_bold-font">Запрос заказчика и принятое решение</h2> <p class="text">РУП «Издательство «Белбланкавыд» специализируется на разработке и реализации разной печатной продукции. В ассортиментном перечне — календари, книги учета, бланки строгой отчетности и так далее. Приобрести товары можно как в торговых объектах сети, так и через <nobr>интернет-магазин</nobr> (самовывоз заказов осуществляется в пунктах выдачи). </p> <blockquote>Техподдержка пользователей осуществляется через портал <a href="https://support.belblank.by/">https://support.belblank.by/</a> (WordPress) посредством системы управления заявками на техподдержку osTicket. Служба сопровождения издательства представлена трехуровневым подразделением РУП, которое взаимодействует с клиентами и оказывает им помощь в решении возникающих вопросов. Также в работе издательства используется <a target="_blank" href="https://techin.by/bitriks24/">система Битрикс24</a>. </blockquote> <img src="/cases/BelBankavyd/sklad_i_assort_04.jpg" title="belbankavyd-case"> <p class="text">Главная проблема заключалась в том, что обращения клиентов, которые поступили в адрес поддержки через портал support.belblank.by, невозможно было отслеживать и сопровождать в Битрикс24. По факту вопросы техподдержки решались исключительно через osTicket на платформе, не связанной с Bitrix. Соответственно, запросы пользователей нельзя было проанализировать в системе, получить статистические данные по ним.</p> <p class="standart_bold-font mb-1">Для решения данной <nobr>бизнес-проблемы</nobr> было принято решение</p> <ul class="standart__list"> <li class="standart__list-item"><p>Настроить интеграцию портала support.belblank.by на основе osTicket с системой Битрикс24.<br><br> Технология, которую планировалось использовать (WebHook) предполагала уведомление сторонних приложений посредством отправки уведомлений о событиях с помощью <nobr>HTTP-запросов</nobr>, произошедших в osTicket или Битрикс24. Такой вариант был оптимальным для работы с REST <acronym title="Application programming interface" lang="en">API</acronym>.</p></li> <li class="standart__list-item"><p>Также планировалась реализация <nobr>cron-скриптов</nobr> на стороне osTicket и Битрикс24 для предупреждения ошибок в интеграции вебхуков. </p></li> <li class="standart__list-item"><p>Со стороны osTicket предполагалась реализация плагина, который является контейнером над библиотекой SDK (@bitrix/crest), также на osTicket было запланировано создание Endpoints для приема уведомлений из <a target="_blank" href="https://techin.by/bitriks24/">Битрикс24</a>.</p></li> </ul> <p class="text">При этом стоит отметить, что в процессе выполнения заказа ТЗ несколько раз менялось. </p> <h2 class="standart_h2 standart_bold-font">Процесс выполнения работ и возникшие сложности</h2> <p class="text">Итогом настройки синхронизации должно было стать объединение трех систем (WordPress, osTicket и Битрикс24) для того, чтобы информация, поступающая в одну из них, автоматически дублировалась и в оставшихся двух. Изначально интеграция предполагалась через открытые линии посредством создания кастомного коннектора телефонии. Но выбранный вариант не устроил заказчика <nobr>из-за</nobr> несоответствий в плане функционала и механизма работы.<br><br> Тогда было принято решение изменить модуль интеграции: переписать все через сделки, воронки продаж и комментарии. Но и здесь возникли сложности, связанные с недостаточной автоматизацией. Дело в том, что тикеты могли «прилетать» не только от компаний, но и их филиалов. Если речь идет о филиале, то, по сути, в Битрикс24 это должна была быть отдельная компания, то есть филиалы и компании нужно было <nobr>как-то</nobr> разграничивать. Но существовала проблема с УНП: в Bitrix действует принцип 1 УНП=1 компания, но по факту под одним учетным номером налогоплательщика (УНП) могло быть множество компаний (головной офис и филиалы).<br><br> Заказчику было предложено решение, которое предполагало, что пользователь получает возможность выбрать филиал или компанию (предусматривалось заполнение специальной формы при оформлении заявки на WordPress).</p> <h3 class="standart_h3 standart_bold-font">Планировалось, что процесс будет следующим</h3><br> <ol class="standart__list"> <li class="standart__list-item"> <p class="stage-num"> 1 </p> <div class="stage-line"> </div> <p>через <acronym title="Application programming interface" lang="en">API</acronym> по УНП осуществляется поиск компании, высвечивается ее наименование;</p></li> <li class="standart__list-item"> <p class="stage-num"> 2 </p> <div class="stage-line"> </div> <p>пользователь может выбрать, это его компания или филиал;</p></li> <li class="standart__list-item"> <p class="stage-num"> 3 </p> <div class="stage-line"> </div> <p>если речь шла о филиале, предусматривался выбор из уже существующих или создание нового;</p></li> <li class="standart__list-item"> <p class="stage-num"> 4 </p> <div class="stage-line"> </div> <p>если такого контакта еще нет в системе Битрикс24, он создается, если есть — прикрепляется к сделке.</p></li> </ol><br> <img src="/cases/BelBankavyd/BBV-case.png" title="BBV-case"> <blockquote class="m-0">Но заказчика этот вариант не устроил. Он хотел, чтобы каждый филиал автоматически попадал в систему, дублировался в WordPress, osTicket и Битрикс24, а у пользователя, который оформлял заявку на поддержку, не было возможности вносить <nobr>какие-либо</nobr> изменения в эти данные для минимизации риска ошибок. </blockquote> <p class="text">Несмотря на время, затраченное на реализацию запросов заказчика и поиск подходящих для этого решений, проект полностью так и не был воплощен в жизнь. Основные причины — постоянно меняющиеся требования со стороны заказчика и специфика программных продуктов, используемых РУП «Издательство «Белбланкавыд». </p>

Запрос заказчика и принятое решение

РУП «Издательство «Белбланкавыд» специализируется на разработке и реализации разной печатной продукции. В ассортиментном перечне — календари, книги учета, бланки строгой отчетности и так далее. Приобрести товары можно как в торговых объектах сети, так и через интернет-магазин (самовывоз заказов осуществляется в пунктах выдачи).

Техподдержка пользователей осуществляется через портал https://support.belblank.by/ (WordPress) посредством системы управления заявками на техподдержку osTicket. Служба сопровождения издательства представлена трехуровневым подразделением РУП, которое взаимодействует с клиентами и оказывает им помощь в решении возникающих вопросов. Также в работе издательства используется система Битрикс24.

Главная проблема заключалась в том, что обращения клиентов, которые поступили в адрес поддержки через портал support.belblank.by, невозможно было отслеживать и сопровождать в Битрикс24. По факту вопросы техподдержки решались исключительно через osTicket на платформе, не связанной с Bitrix. Соответственно, запросы пользователей нельзя было проанализировать в системе, получить статистические данные по ним.

Для решения данной бизнес-проблемы было принято решение

Настроить интеграцию портала support.belblank.by на основе osTicket с системой Битрикс24.

Технология, которую планировалось использовать (WebHook) предполагала уведомление сторонних приложений посредством отправки уведомлений о событиях с помощью HTTP-запросов, произошедших в osTicket или Битрикс24. Такой вариант был оптимальным для работы с REST API.
Также планировалась реализация cron-скриптов на стороне osTicket и Битрикс24 для предупреждения ошибок в интеграции вебхуков.
Со стороны osTicket предполагалась реализация плагина, который является контейнером над библиотекой SDK (@bitrix/crest), также на osTicket было запланировано создание Endpoints для приема уведомлений из Битрикс24.

При этом стоит отметить, что в процессе выполнения заказа ТЗ несколько раз менялось.

Процесс выполнения работ и возникшие сложности

Итогом настройки синхронизации должно было стать объединение трех систем (WordPress, osTicket и Битрикс24) для того, чтобы информация, поступающая в одну из них, автоматически дублировалась и в оставшихся двух. Изначально интеграция предполагалась через открытые линии посредством создания кастомного коннектора телефонии. Но выбранный вариант не устроил заказчика из-за несоответствий в плане функционала и механизма работы.

Тогда было принято решение изменить модуль интеграции: переписать все через сделки, воронки продаж и комментарии. Но и здесь возникли сложности, связанные с недостаточной автоматизацией. Дело в том, что тикеты могли «прилетать» не только от компаний, но и их филиалов. Если речь идет о филиале, то, по сути, в Битрикс24 это должна была быть отдельная компания, то есть филиалы и компании нужно было как-то разграничивать. Но существовала проблема с УНП: в Bitrix действует принцип 1 УНП=1 компания, но по факту под одним учетным номером налогоплательщика (УНП) могло быть множество компаний (головной офис и филиалы).

Заказчику было предложено решение, которое предполагало, что пользователь получает возможность выбрать филиал или компанию (предусматривалось заполнение специальной формы при оформлении заявки на WordPress).

Планировалось, что процесс будет следующим

1

через API по УНП осуществляется поиск компании, высвечивается ее наименование;
2

пользователь может выбрать, это его компания или филиал;
3

если речь шла о филиале, предусматривался выбор из уже существующих или создание нового;
4

если такого контакта еще нет в системе Битрикс24, он создается, если есть — прикрепляется к сделке.

Но заказчика этот вариант не устроил. Он хотел, чтобы каждый филиал автоматически попадал в систему, дублировался в WordPress, osTicket и Битрикс24, а у пользователя, который оформлял заявку на поддержку, не было возможности вносить какие-либо изменения в эти данные для минимизации риска ошибок.

Несмотря на время, затраченное на реализацию запросов заказчика и поиск подходящих для этого решений, проект полностью так и не был воплощен в жизнь. Основные причины — постоянно меняющиеся требования со стороны заказчика и специфика программных продуктов, используемых РУП «Издательство «Белбланкавыд».

Запрос заказчика и принятое решение

Процесс выполнения работ и возникшие сложности

Планировалось, что процесс будет следующим

Оставить заявку