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

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

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

Техподдержка пользователей осуществляется через портал 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. 1

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

2. 2

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

3. 3

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

4. 4

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

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

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