Zammad в бою: подключаем Telegram, почту и веб-чат, синхронизируем Active Directory и переезжаем с общего ящика без потери истории

Диагноз: почему общий ящик поддержки — это бомба замедленного действия

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы занимаемся IT-аутсорсингом для юрлиц до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС и почти каждый второй новый клиент приходит к нам с одной и той же схемой поддержки: общий почтовый ящик вроде support@company.ru, к которому подключены двое-трое сотрудников через обычный почтовый клиент. Работает это ровно до первого сбоя. В обзорной статье серии я разбирал, чем Zammad отличается от Zendesk и кому он подходит вообще; здесь — про то, как мы физически переводим клиента с «поддержки в почте» на тикеты и подключаем все каналы. Установку самого сервера я вынес в отдельный материал про разворачивание Zammad 7.1 на VPS — предполагаю, что сервер у вас уже поднят и открывается по HTTPS.

Сначала честно про то, почему общий ящик — это не «дёшево и сердито», а отложенная авария:

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

Тикет-система решает всё это структурно, а не силой воли сотрудников: у каждого обращения есть один владелец, статус, срок реакции (SLA), и вся история подшита к клиенту и к его организации. Дальше — по каналам, как мы их подключаем на реальных внедрениях.

Email-канал по-взрослому

Почта остаётся главным каналом B2B-поддержки, и именно на ней ломаются 90% самодельных внедрений. В Zammad почтовый канал — это связка IMAP на приём и SMTP на отправку: система забирает входящие письма из ящика support@ и превращает каждое в тикет, а ответы агентов уходят обратно тем же адресом. Ящик мы заводим отдельный, на своём почтовом сервере или у российского хостера — не на личной почте сотрудника и не на бесплатном сервисе.

Фильтры на входе: не плодим мусорные тикеты

Первое, что убивает молодое внедрение, — это когда в тикеты превращается всё подряд: автоответы, уведомления биллинга, алерты мониторинга, рассылки. Через день агенты тонут в шуме и перестают доверять системе. Поэтому на входе настраиваем правила:

• письма от no-reply-адресов и рассылок — не создают тикет либо уходят в отдельную неотслеживаемую группу;
• служебные уведомления мониторинга обрабатываются отдельно (об этом ниже, в разделе про API — там им место);
• автоответы «я в отпуске» распознаём по заголовкам и не реанимируем ими закрытые тикеты.

Защита от почтовых петель

Классическая катастрофа: ваш автоответ «мы получили обращение» уходит на адрес, который сам шлёт автоответ, тот триггерит ваш — и два робота за минуту генерируют сотни писем. Zammad по умолчанию отслеживает свои служебные заголовки и распознаёт собственные автоответы, чтобы не зациклиться, но это надо проверять на этапе внедрения тестовой перепиской, а не после. Отдельно ограничиваем частоту автоответов одному и тому же отправителю.

SPF, DKIM и почему ответы агентов не должны падать в спам

Если ответы поддержки улетают клиентам в «Спам», клиент считает, что его игнорируют, — это прямой репутационный удар. Поэтому для ящика поддержки обязательно настраиваем SPF и DKIM на стороне почтового сервера: домен, от имени которого Zammad шлёт ответы, должен проходить проверку подписи и разрешённых отправителей. Без этого даже идеально настроенная тикет-система будет выглядеть в глазах клиента молчащей. Подписи и шаблоны ответов настраиваем сразу под бренд клиента, чтобы письмо из Zammad не отличалось от письма живого менеджера.

Telegram-бот пошагово (с нюансами работы из РФ)

Telegram у российских клиентов давно перегнал почту по скорости: люди пишут в мессенджер и ждут ответа за минуты. Zammad умеет принимать обращения через Telegram-бота и складывать их в те же тикеты, что и почту, — агент даже не переключает интерфейс. Разберём подключение по шагам.

1. Создаём бота через BotFather. В Telegram пишем официальному боту @BotFather, командой создаём нового бота, задаём ему имя и получаем токен — длинную строку вида 123456789:AAxx.... Это ключ доступа к боту, обращаемся с ним как с паролем.
2. Вставляем токен в админку Zammad. В разделе каналов добавляем Telegram-канал и вставляем полученный токен. Zammad проверяет его и привязывает бота к системе.
3. Валидный HTTPS-сертификат — обязательное условие. Telegram доставляет сообщения боту через webhook, а webhook он ставит только на адрес с валидным сертификатом. Самоподписанный или просроченный сертификат — и канал просто не встанет, без внятной ошибки. Поэтому Zammad должен быть опубликован по HTTPS с нормальным сертификатом (Let's Encrypt подойдёт) ещё до подключения бота.
4. Проверяем диалог. Клиент пишет боту как обычному человеку в личку; на стороне агента это выглядит как обычный тикет, ответ уходит из веб-интерфейса Zammad и приходит клиенту в Telegram.

Групповая маршрутизация

Можно завести не одного бота, а несколько — и направить их в разные группы агентов. Например, бот @company_support идёт в группу техподдержки, а @company_sales — в группу продаж. Для клиента это два разных контакта, для нас — единая система с правильной маршрутизацией тикетов сразу в нужную команду.

Веб-чат на сайт компании

Веб-чат Zammad — это JavaScript-сниппет, который вставляется в футер сайта клиента. Появляется привычный «пузырёк» в углу страницы. Ключевое отличие от большинства виджетов: чат мы настраиваем так, чтобы он показывался только когда агенты онлайн. Это честнее, чем висящее круглосуточно окошко, которое собирает сообщения в пустоту, а клиент потом три дня ждёт ответа и злится. Нет онлайн-агента — нет иллюзии живого чата; посетителю предлагаем почту или форму.

Что настраиваем под каждого клиента:

• Цвет и заголовок под бренд — чтобы виджет выглядел частью сайта, а не инородной вставкой.
• Триггер-приветствие — сообщение, которое всплывает через несколько секунд на нужных страницах («Здравствуйте! Подсказать по тарифам?»).
• Ограничение по страницам — например, чат только в разделе поддержки, а не на странице вакансий.

Главное: диалог из чата — это полноценный тикет с историей. Клиент начал в чате, ушёл с сайта, а продолжение переписки спокойно уходит ему на почту в рамках того же тикета. Для агента всё это — одна карточка, а не три разрозненных разговора в трёх системах.

Клиентский портал и веб-форма

Веб-форма — это ещё один способ принять обращение прямо с сайта, без того чтобы клиент открывал почту. Готовый блок с полями (тема, описание, вложение) вставляется на страницу «Поддержка» или «Контакты» и создаёт тикет напрямую. Удобно для тех, кто не хочет писать письмо и не сидит в Telegram.

Отдельная история — клиентский портал, личный кабинет, где клиент видит свои тикеты, их статусы и историю обращений. Вот тут важно не переусердствовать с внедрением, и мы честно объясняем это клиентам:

Логика простая: портал имеет смысл там, где клиент регулярно возвращается и ему важна прозрачность статусов по договору. Для разового потока обращений он только добавляет барьер «зарегистрируйтесь и войдите» — проще оставить почту и мессенджер.

LDAP/Active Directory: агенты и сотрудники без ручного заведения

Если у клиента есть домен Active Directory, заводить в Zammad пользователей руками — трата времени и источник рассинхрона. Zammad подключается к AD по протоколу LDAP и подтягивает учётные записи автоматически.

Маппинг атрибутов и групп на роли

Ценность интеграции не в том, что «подтянулись имена», а в маппинге. Мы настраиваем соответствие:

• атрибуты AD → поля Zammad: displayName в имя, mail в email, department в организацию;
• группы AD → роли Zammad: члены группы Helpdesk получают роль «Агент», все остальные — роль «Клиент». Добавили сотрудника в группу в домене — он автоматически стал агентом в Zammad, без ручных действий.

Расписание синхронизации и главная ошибка

Синхронизация идёт по расписанию, так что кадровые изменения (новый сотрудник, увольнение) подхватываются сами. И тут — грабли, на которые наступают почти все:

А если AD нет?

Небольшие фирмы часто живут без домена. Тогда два пути: разовый импорт пользователей из CSV (выгрузка из 1С или Excel) и автосоздание клиентов из входящих писем — написал человек впервые на support@, Zammad сам завёл на него карточку клиента. Для B2C-потока второго варианта обычно достаточно, база клиентов наполняется естественным образом.

REST API и вебхуки: Zammad как часть ИТ-ландшафта

Здесь Zammad перестаёт быть просто «красивой почтой» и становится узлом инфраструктуры. У него есть полноценный REST API с токен-авторизацией: можно создать тикет, обновить, найти, назначить — всё одним HTTP-запросом. Токен генерируется в профиле пользователя, и запросы идут от его имени с нужными правами.

Наш рабочий паттерн: мониторинг сам заводит тикеты

Самая полезная интеграция на практике — связка с системой мониторинга. Zabbix ловит падение критичного сервера и через API Zammad заводит тикет с приоритетом high — дежурный видит инцидент в той же очереди, что и обращения клиентов, ничего не теряется в почте алертов. Упрощённо запрос выглядит так:

curl -X POST https://help.company.ru/api/v1/tickets \
  -H "Authorization: Token token=ВАШ_ТОКЕН" \
  -H "Content-Type: application/json" \
  -d '{
    "title": "Zabbix: недоступен сервер SRV-01",
    "group": "Мониторинг",
    "customer_id": "guess:monitoring@company.ru",
    "priority_id": 3,
    "article": {
      "subject": "CRITICAL",
      "body": "Хост SRV-01 не отвечает на ICMP более 5 минут",
      "type": "note",
      "internal": false
    }
  }'

Тот же механизм используем, чтобы принимать заявки из 1С или клиентской CRM: нажал сотрудник «создать обращение в поддержку» — ушёл POST в Zammad, тикет появился в очереди. Никакого дублирования систем, единое окно для поддержки.

Вебхуки наружу

Если API — это «снаружи внутрь», то вебхуки — «изнутри наружу»: Zammad сам дёргает внешний URL, когда что-то происходит. Наш типовой сценарий — эскалация SLA: тикет просрочен, Zammad шлёт вебхук в служебный Telegram-канал дежурной смены, и инженер получает пинг раньше, чем клиент успевает написать «ну где вы там». Комбинация «вебхук на эскалацию + мониторинг через API» превращает тикет-систему из пассивного ящика в активного участника дежурства.

Миграция: как переехать и ничего не потерять

Самая нервная часть внедрения. Клиент боится ровно одного: «а старые обращения не потеряются?». Отвечаю по сценариям.

Переезд с другой тикет-системы

Если клиент уже жил на OTRS, Zendesk или Freshdesk, всё проще, чем кажется: у Zammad есть встроенные импортёры под эти три системы. Они переносят тикеты, историю переписки и пользователей. Мы всегда сначала гоняем импорт на тестовой копии, сверяем количество тикетов и выборочно — содержимое, и только потом делаем боевой переезд.

Переезд с «просто почты»

Самый частый случай у наших клиентов. Здесь фокус в том, что старый ящик support@ мы подключаем к Zammad как обычный email-канал. Дальше два эффекта: новые письма сразу становятся тикетами, а накопленный архив писем при первичной синхронизации заезжает в систему и становится историей. Ни одно письмо не остаётся «снаружи».

Период двоевластия

Резко рубить старый процесс нельзя — половина клиентов ещё пишет по старинке. Мы закладываем переходный период около двух недель:

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

Контрольные точки

Главный принцип миграции: ни одно письмо переходного периода не должно потеряться. Поэтому в первые дни ежедневно сверяем: число входящих на почтовом сервере = число созданных тикетов + отфильтрованный мусор. Расхождение — сразу разбираем, где письмо застряло (обычно это переусердствовавший фильтр). Такой контроль занимает 10 минут в день, а спасает от репутационной дыры «мы вам писали, а вы не ответили».

Что вас ждёт после переезда: честные наблюдения

Обещать, что «всё сразу станет прекрасно», было бы враньём. По опыту нескольких внедрений вот что происходит на самом деле:

• Первые две недели агенты тихо ненавидят статусы и владельцев. После свободы общего ящика необходимость выставлять статус, брать тикет в работу и закрывать его кажется бюрократией. Это нормально и проходит. Помогает короткий регламент на одну страницу и один человек, который следит за дисциплиной первые дни.
• Через месяц приходит первая любовь к поиску. Наступает момент «а найди-ка мне тот тикет за март, где мы что-то настраивали этому клиенту» — и он находится за десять секунд. С этого момента возврата к общему ящику уже не хочет никто.
• Метрики всплывают наружу — и это не всем приятно. Внезапно видно, кто отвечает быстро, а у кого тикеты висят по неделе. Руководителю это подарок, отдельным сотрудникам — стресс. Мы предупреждаем об этом заранее, чтобы прозрачность не стала неожиданностью.
• Кастомизация глубже галочек потребует Ruby. Zammad написан на Ruby (фреймворк Rails). Всё, что настраивается мышкой в админке — каналы, роли, триггеры, SLA, — вы сделаете сами. Но как только захочется нестандартной логики, своих объектов или хитрой автоматизации за пределами штатных возможностей, понадобится программист на Ruby. Это не недостаток, это граница: закладывайте её в ожидания и в бюджет сразу, чтобы потом не было сюрприза «а почему нельзя просто вот так».

В сухом остатке: Zammad честно закрывает 95% задач поддержки силами админа и мыши, а на оставшиеся 5% нужен либо разработчик, либо разумный компромисс. Мы обычно помогаем клиентам провести именно эту границу трезво — без розовых обещаний и без лишнего кодинга там, где хватит штатной галочки.