Интеграция
Zendesk и один разговор, который не должен раздваиваться
Интеграция с Zendesk превращает эскалированный разговор в заявку и гоняет ответы в обе стороны: клиент остаётся в Telegram, агент — в Zendesk. Сложное здесь — опознание человека: без устойчивого сопоставления обратившегося каждый новый разговор заводит нового пользователя.
Zendesk — интеграция: доступ, лимиты и доступность
- Модель авторизации
- Ключ API
- Лимит частоты
- На аккаунт, зависит от тарифа; 429 с Retry-After
- Доступность в Заливе
- Региональных ограничений нет; выбор места хранения на части тарифов
- Поток данных
- 5 переходов, через воркер
As of 2025-10-01, Telegram Bot API 13.4
Зачем нужна эта интеграция
Команда поддержки, которая уже живёт в Zendesk, держит там отчётность по SLA, свои макросы и весь рабочий процесс агента, и ничто из этого не должно переезжать только потому, что появился ещё один канал. Значит, задача не в том, чтобы заменить Zendesk, а в том, чтобы Telegram вёл себя как ещё один питающий его канал, а разговор при этом оставался там, где клиент уже находится.
Опознание человека — то, от чего зависит, получится ли вообще. Zendesk привязывает заявку к обратившемуся, а пользователь Telegram приходит с числовым идентификатором и отображаемым именем: без почты и, как правило, без телефона. Заводить отдельного обратившегося на каждый разговор — значит получить историю обращений, размазанную по десяткам пользователей, которые на самом деле один и тот же человек, и тихо разрушить ту самую отчётность, ради которой команда когда-то и выбрала Zendesk.
Вторая проблема — петли. Бот кладёт сообщение клиента в заявку, срабатывают собственные триггеры Zendesk, обратно приходит уведомление, бот отправляет его клиенту. Без явной метки, которая отличает комментарий, созданный ботом, от комментария агента, ветка поддержки способна зациклиться в бесконечный обмен — ровно настолько неловко на глазах у клиента, насколько это и звучит.
Как на самом деле движутся данные
Токен API в паре с почтой агента — либо токен OAuth, если интеграция обслуживает несколько аккаунтов, — хранится как секрет воркера. Интеграция аутентифицируется от имени отдельного служебного агента, а не живого сотрудника: тогда история заявок корректно относит автоматические действия к интеграции и не ломается в тот день, когда человек уходит из компании.
Модель доступа: API-ключ
Их лимиты и что они означают для вас
Zendesk применяет лимиты частоты на аккаунт, они зависят от тарифа и при превышении отдают 429 с заголовком Retry-After.
Заголовок соблюдается, а не подменяется собственной локальной паузой. Трафик поддержки по природе рваный, поэтому упереться в лимит проще всего во время инцидента — то есть ровно тогда, когда это важнее всего.
Заявка связана с обратившимся, а обратившихся обычно опознают по адресу электронной почты.
У пользователя Telegram почты нет. Либо при первом контакте создаётся устойчивое сопоставление с внешней личностью, либо история клиента рассыпается на каждом новом разговоре.
Комментарии бывают публичными и внутренними, и именно это различие решает, что увидит клиент.
В Telegram уходят только публичные комментарии. Переслать клиенту внутреннюю заметку — запоминающийся провал, которого элементарно избежать.
Триггеры и автоматизации срабатывают на заявках, созданных через API, ровно так же, как на любых других.
Отработает вся уже настроенная автоматика. Разобрать её — часть оценки работ: автоответ на почту обратившемуся, у которого почты нет, отказывает запутанным образом.
Как это ломается и что происходит потом
Бот и Zendesk начинают отвечать друг другу по кругу.
Комментарии, созданные ботом, помечаются и игнорируются на обратном пути. Без этого ветка поддержки способна бесконечно дублировать саму себя прямо на глазах у клиента.
Один клиент превращается в нескольких пользователей Zendesk.
Карта обратившихся строится на идентификаторе пользователя Telegram. Склеить всё это задним числом можно, но неприятно, — поэтому сопоставление выбирают до первой заявки, а не после сотой.
Внутренняя заметка уходит клиенту.
Границу пересекают только публичные комментарии, и проверка на это явная, а не выведенная из оформления. Агенты пишут внутренние заметки в расчёте на приватность и имеют на это полное право.
Лимит частоты срабатывает в момент передачи ответа агента.
Ретрансляция встаёт в очередь и повторяется, поэтому ответ агента приходит с опозданием, а не никогда. Молча его потерять — значит оставить агента в уверенности, что он ответил.
Доступность в ОАЭ и остальных странах Залива
Весь мир
Региональных ограничений нет. На части тарифов есть выбор места хранения данных, и его стоит подтвердить там, где это небезразлично регулятору.
Действующие клиенты Zendesk
Тот самый случай, ради которого всё это и делается. Если команда ещё не работает в Zendesk, эта интеграция — повод подумать ещё раз, а не повод его внедрять.
Тарифы Suite против тарифов только с Support
Доступность API и лимиты частоты зависят от тарифа. Подтвердите их до оценки работ: лимиты формируют устройство ретрансляции, а не просто слегка её ограничивают.
Наличие песочницы
Есть на старших тарифах и здесь по-настоящему полезна, потому что побочные эффекты триггеров — главный источник сюрпризов.
Когда эту интеграцию делать не нужно
- Ваша команда ещё не работает в Zendesk. Заводить хелпдеск ради интеграции с ним — это хвост, виляющий собакой.
- У вас несколько обращений в день. С этим справится отдельная тема в форуме Telegram, и стоить она не будет ничего.
- Вы хотите, чтобы бот закрывал заявки сам. Решение о закрытии — это суждение, а автоматическое закрытие даёт цифры по SLA, в которые никто не верит.
- Никто не может объяснить, что именно делают ваши триггеры. Они сработают на каждой созданной ботом заявке, и сюрпризы обнаружатся прямо на глазах у клиентов.
На чём это работает
| Компонент | Версия | Зачем |
|---|---|---|
| Cloudflare Workers | current | Создание заявок, ретрансляция комментариев и обработка входящих webhook. |
| Cloudflare D1 | current | Карта обратившихся, связки заявки с разговором и состояние ретрансляции. |
| Zod | 4.4 | Проверка полезной нагрузки webhook и ответов внешнего API. |
| grammY | 1.45 | Разговор с клиентом и сама передача обращения человеку. |
Вопросы, которые возникают при оценке
Как пользователь Telegram становится обратившимся в Zendesk?
Через устойчивое сопоставление, которое создаётся при первом контакте и строится на идентификаторе пользователя Telegram. Без него каждый разговор заводит нового пользователя, история клиента рассыпается, и это тихо ломает ту отчётность, ради которой команда и выбирала Zendesk.
Что мешает боту и Zendesk отвечать друг другу до бесконечности?
Комментарии, созданные ботом, несут метку и игнорируются, когда возвращаются через webhook. Деталь мелкая, а её отсутствие даёт ветку, которая дублирует саму себя на глазах у клиента.
Смогут ли агенты и дальше пользоваться внутренними заметками?
Да, и наружу уходят только публичные комментарии. Проверка явная, а не выведенная из оформления: агент пишет внутреннюю заметку в расчёте на приватность, и это допущение обязано выполняться.
Что станет с нашими уже настроенными триггерами Zendesk?
Они сработают на созданной ботом заявке ровно так же, как на любой другой. В том числе автоответ на почту обратившемуся, у которого почты нет: отказывает это запутанно, пока кто-нибудь не разберёт автоматику по шагам.
Стоит ли разрешать боту закрывать заявки?
Нет. Закрытие — это суждение, а автоматическое закрытие даёт цифры по SLA, которым ваша же команда перестанет доверять. Бот передаёт и эскалирует, а решение о том, что вопрос закрыт, принимает человек.
Что будет, если лимит частоты сработает прямо посреди разговора?
Ретрансляция встаёт в очередь и повторяется с той паузой, которую назвал сам Zendesk в заголовке Retry-After. Ответ агента приходит с опозданием, а не пропадает: молча потерянный ответ оставляет агента в уверенности, что он уже ответил.
Что почитать дальше
Если нужен хелпдеск полегче с такой же схемой ретрансляции, смотрите интеграцию с Freshdesk.
Разговор до момента эскалации ведёт слой, который описывает разбор многоязычного бота поддержки.
Как замкнуть круг после закрытой заявки, показывает разбор бота сбора отзывов.
Жалоба, ставшая публичным отзывом, требует ответа в обоих местах — про это читайте интеграцию с Google Business Profile.
Чтобы сократить сам объём того, что приходится эскалировать, посмотрите на уровень ИИ-ассистента.