Zammad вместо Zendesk: честный обзор бесплатного service desk, который мы ставим клиентам в 2026 году

Почему малому бизнесу в 2026 снова нужен service desk

Меня зовут Семёнов Евгений Сергеевич, я технический директор ITfresh. Мы занимаемся IT-аутсорсингом для компаний до 50 рабочих мест в Москве, держим собственные серверы в дата-центре МТС и за 15 с лишним лет насмотрелись, как в небольших фирмах устроена работа с обращениями клиентов. А устроена она почти всегда одинаково: общий почтовый ящик info@, пара личных WhatsApp сотрудников и групповой чат, где «кто первый увидел, тот и ответил». Пока в компании три человека, это работает. На десяти-пятнадцати — ломается.

Ломается предсказуемо. Обращение приходит в личку менеджера, который в отпуске, — и висит там, пока клиент не позвонит с претензией. У задачи нет ответственного: все думают, что ответит кто-то другой. Нет истории: новый сотрудник не видит, о чём с этим клиентом договаривались полгода назад. Нет ни одной цифры о том, сколько обращений в день, за какое время на них отвечают и сколько потерялось совсем. По нашей практике фирма на 30 рабочих мест без нормальной системы учёта обращений теряет до 15% входящих просто потому, что они проваливаются между людьми и каналами. Для сервисной компании это прямые деньги.

Лет пять назад ответ был очевиден: берёшь Zendesk или Freshdesk, платишь за агента в месяц и не думаешь. Сегодня этих вариантов у российской компании фактически нет — западные SaaS-помощники из РФ ушли, оплата картой не проходит, а хранить переписку с клиентами в облаке, к которому в любой момент могут отключить доступ, — так себе идея. Остаются российские SaaS-тикетницы, но они берут от 1000–2000 рублей за агента в месяц, и на команде поддержки из пяти человек это уже ощутимая ежемесячная строка расходов, которая растёт с каждым новым сотрудником. Плюс те же вопросы к тому, где физически лежат данные.

Поэтому в 2026 году мы всё чаще возвращаемся к тому, с чего IT-индустрия когда-то начинала, — к self-hosted системам с открытым кодом, которые ставятся на свой сервер, не требуют абонентской платы и держат данные внутри периметра компании. Перебрав для клиентов полтора десятка таких систем, в семи внедрениях из десяти мы теперь ставим Zammad. Ниже — честный разбор, почему именно его, где он выигрывает, а где честно проигрывает.

Наша методика выбора: 8 критериев для фирмы до 50 РМ

Чтобы не выбирать «по красоте лендинга», мы прогоняем каждого кандидата через восемь критериев. Они выстраданы внедрениями и заточены именно под небольшую компанию, а не под корпорацию с отделом ITSM.

1. Self-hosted, данные у себя. Система ставится на наш или клиентский сервер, переписка с клиентами не уезжает в чужое облако. Это не паранойя, а требование к бизнесу, который отвечает за персональные данные своих заказчиков.
2. Русский интерфейс — и для агентов, и для клиентов. Не «энтузиасты когда-то перевели половину меню», а живая, полная локализация. Агент, который спотыкается об английские кнопки, работает медленнее и злится.
3. Каналы email, Telegram и веб-чат из коробки. Российский клиент пишет в Telegram, а не заводит тикет на портале. Система, которая этого не умеет без бубна, для нашей ЦА бесполезна.
4. SLA и автоматизации. Сроки реакции, эскалации, автоответы, автоназначения — без программирования, настройками через интерфейс.
5. Живой релизный цикл. Проект должен развиваться: регулярные релизы, закрытие уязвимостей, а не «последний коммит два года назад».
6. Совокупная стоимость владения за три года. Не только лицензия (у open source она нулевая), но и сервер, обслуживание, обновления. Считаем горизонтом в три года.
7. Порог входа для приходящего админа. Систему потом кто-то сопровождает. Чем проще её развернуть, обновить и починить, тем дешевле она в жизни.
8. Открытый API. Рано или поздно тикетницу нужно связать с 1С, CRM или мониторингом. Без REST API это тупик.

По этим восьми пунктам большинство кандидатов отвалилось быстро. Проприетарные SaaS — на первом же критерии (данные не у себя, ежемесячная плата). Заброшенные open source-проекты — на живом релизном цикле. Несколько систем прекрасны для крупного ITSM, но перегружены для фирмы на 30 человек: их порог входа не окупается. В сухом остатке из полутора десятков реальными финалистами для нашей ЦА оказались три: Zammad, GLPI и osTicket. Дальше разберу, почему для поддержки клиентов чаще всего побеждает Zammad, а сравнительную таблицу всех трёх плюс российских SaaS приведу в отдельном разделе.

Что такое Zammad и почему ему можно доверять

Zammad — это open source service desk, то есть система для приёма и обработки обращений: тикеты, каналы связи, SLA, база знаний. Проект живёт с 2016 года, и у него важная родословная: основатель Zammad — автор OTRS, одной из самых известных классических тикет-систем. То есть за проектом стоит человек, который делал системы поддержки задолго до нынешней волны, и Zammad — это переосмысление того опыта на современном стеке. Актуальная версия на момент написания — 7.1.1, вышла в июне 2026.

Ключевой для бизнеса момент — лицензия. Zammad распространяется под AGPLv3, и в self-hosted-варианте он бесплатен полностью: без лимитов на количество агентов и тикетов и без урезанной «community-версии», из которой вырезали половину функций, чтобы продать вам платную. Это принципиальное отличие от многих «условно-бесплатных» продуктов: вы не упрётесь в стеклянный потолок на пятом агенте. У проекта есть и платное облако с поддержкой — но это именно хостинг и сопровождение от вендора, а не «функции за деньги». Разворачиваете сами — получаете всё.

Про AGPLv3 у клиентов всегда один и тот же тревожный вопрос: «а нас не заставят открыть свой код?». Отвечаю честно, как мы это объясняем сами: для компании, которая просто использует Zammad внутри себя как инструмент поддержки, — не заставят ничего. Обязательства AGPL про раскрытие исходников возникают у того, кто модифицирует Zammad и предоставляет его как сетевой сервис третьим лицам. Вы ставите систему, работаете в ней, общаетесь с клиентами — вы пользователь, а не распространитель. Никаких юридических страшилок здесь нет; это стандартная ситуация для тысяч компаний по всему миру.

Под капотом — взрослый стек: Ruby on Rails как основа приложения, PostgreSQL для данных, Redis для кэша и фоновых очередей, Elasticsearch для полнотекстового поиска. Стек проверенный, но не самый лёгкий — к его аппетитам я ещё вернусь в разделе про минусы. Релизы выходят регулярно, уязвимости закрываются, ветка 7.x активно развивается — по критерию «живой проект» Zammad проходит без вопросов.

Каналы приёма обращений

Главная ценность service desk в том, что все обращения из разных каналов стекаются в одну ленту, привязанную к клиенту и его истории. Клиент пишет как ему удобно — почтой, в Telegram, в чат на сайте, — а агент видит единый тикет со всей перепиской. Разберу каналы Zammad по порядку.

Email (IMAP/SMTP)

Базовый и самый нагруженный канал в любом нашем внедрении. Zammad забирает письма из ящика вида support@company.ru по IMAP: каждое письмо становится новым тикетом или ответом в существующем, а отвечает агент через тот же ящик по SMTP. Работает с любым почтовым сервером — российский хостинг, свой Postfix, корпоративный почтовик — лишь бы был IMAP и SMTP. Никаких особых требований к провайдеру: это обычная почта, которую система превращает в структурированные обращения.

Telegram-бот из коробки

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

Веб-чат и веб-форма

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

Соцсети — и что из них реально работает в РФ

В арсенале Zammad есть и интеграции с соцсетями. Скажу честно, без маркетинга: для российской ЦА в 2026 году реально работающая связка — это email, Telegram и веб-чат, на них приходится почти весь поток. Интеграции с зарубежными соцсетями существуют, но нашим клиентам они нужны редко, поэтому мы их обычно не поднимаем. Важно, что все каналы сводятся в единую ленту тикета с историей по клиенту: даже если человек сначала написал письмо, а через неделю — в Telegram, агент увидит связку, а не два независимых обрывка.

Ядро системы: чем Zammad зарабатывает лояльность агентов

Каналы — это вход. Дальше начинается то, ради чего агенты в принципе любят или ненавидят систему, — повседневная работа с тикетами. Здесь у Zammad всё выстроено грамотно.

Тикеты и единая история по клиенту и организации

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

SLA с календарями рабочего времени и эскалациями

Zammad считает сроки реакции и решения по настраиваемым SLA, причём с оглядкой на рабочий календарь: если поддержка работает с 9 до 18 по будням, то тикет, пришедший в пятницу вечером, не «горит» всю ночь и выходные — счётчик встаёт до понедельника. Нарушение срока поднимает эскалацию. Это ровно то, что отличает управляемую поддержку от «отвечаем, когда руки дойдут».

Триггеры и планировщик — автоматизация без программирования

Триггеры — это правила «если — то», которые настраиваются мышкой: пришло письмо на support@ — отправить клиенту автоответ «мы получили ваше обращение» и назначить на группу «Техподдержка»; в теме слово «счёт» — поставить приоритет выше и кинуть в бухгалтерию. Планировщик делает то же по расписанию: напомнить об открытых тикетах, автоматически закрыть решённые через N дней. Всё это без единой строки кода — важнейший пункт для компаний, где нет своего разработчика.

База знаний с публичным порталом

Встроенная база знаний работает в двух режимах: внутренняя — для агентов (типовые решения, регламенты), и публичная — портал самообслуживания для клиентов. Хорошо написанная статья «как перенастроить почту на новом телефоне» снимает десятки одинаковых обращений: клиент находит ответ сам. База знаний тоже локализуется на русский.

Полнотекстовый поиск на Elasticsearch

Тот самый Elasticsearch из стека отвечает за поиск — и это не поиск «по точному совпадению», а полнотекстовый по всему: темам и телам тикетов, комментариям, карточкам клиентов и, главное, по содержимому вложений. Запрос «найди тикет, где присылали акт сверки за март» находит нужное за секунду, включая PDF во вложении. Именно ради этого поиска стоит терпеть аппетиты Elasticsearch.

Роли, права и REST API

Права в Zammad раздаются гибко — вплоть до видимости отдельных полей и групп: агент бухгалтерии не видит тикеты техподдержки, стажёр не может закрывать чужие обращения. А открытый REST API позволяет связать Zammad с чем угодно — от создания тикетов из мониторинга до выгрузки статистики в 1С. Про интеграции у нас будет отдельная статья серии.

AI-функции веток 7.0 и 7.1

Тема, которую по-русски пока толком никто не разобрал, поэтому расскажу, что есть на самом деле, отделяя работающее от маркетинга. AI-функции появились в Zammad начиная с ветки 7.0 (март 2026): помощник для агента и суммаризация длинных тикетов. Суммаризация — вещь на удивление практичная: когда тикет растянулся на тридцать сообщений и его передают другому агенту, система коротко пересказывает суть, и человеку не нужно вычитывать всю переписку с нуля.

Но главное для нашей ЦА даже не сами функции, а то, как они устроены: Zammad позволяет подключить собственную LLM на своём железе. Это переворачивает всю историю с «AI в поддержке». Обычно подключение ИИ означает, что переписка ваших клиентов уезжает в чужое облако на обработку — для компании, отвечающей за персональные данные, это стоп-фактор. Здесь же вы можете поднять открытую языковую модель на своём сервере, и данные не покидают периметр компании вообще. Для юрфирмы или клиники, где конфиденциальность — не пожелание, а обязанность, это единственный приемлемый способ вообще притронуться к AI в поддержке.

Теперь честная часть. AI в Zammad на текущих ветках — это полезный помощник, а не замена агенту: он помогает с рутиной (пересказать, подсказать, черновик ответа), но не «сам ведёт поддержку». Локальная LLM требует железа: чтобы модель работала быстро и осмысленно, нужен сервер помощнее того, на котором крутится сам Zammad, — это отдельные затраты, которые надо закладывать заранее. Мы подключаем AI-функции клиентам выборочно: там, где поток тикетов действительно большой и суммаризация экономит время, — да; там, где пять обращений в день, — это игрушка, которая не окупит железо. Трезвый расчёт вместо хайпа.

Русский язык: не «переведено энтузиастами», а системно

Локализация — пункт, на котором спотыкается половина open source-систем: вроде переведено, но наполовину, вперемешку с английским, и половина терминов — калька. У Zammad с этим порядок, и порядок системный.

Русский интерфейс идёт из коробки — его не нужно докручивать. Переводы ведутся не силами случайных энтузиастов, а через собственную платформу перевода на translations.zammad.org (движок Weblate): это структурированный процесс, где строки интерфейса переводятся и вычитываются, а покрытие русского — высокое. Практически всё, что видит агент и клиент, — на нормальном русском.

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

Чего в Zammad нет — честный список

Я обещал честный обзор, поэтому вот раздел, который вендоры писать не любят. У Zammad есть вещи, которых в нём нет, и о них лучше знать до внедрения, а не после.

• Нет CMDB и учёта активов — вообще. Это важнее всего понять сразу: Zammad — система про общение с клиентом, а не про инвентаризацию техники. В нём нельзя вести базу компьютеров, лицензий, серверов и их связей. Если вам нужен учёт активов рядом с заявками — это к другим системам: мы в паре с Zammad ставим GLPI или Snipe-IT именно под инвентаризацию, а Zammad оставляем на то, что он умеет лучше всех, — на поддержку. Пытаться сделать из Zammad ITIL-комбайн с управлением конфигурациями — тупиковый путь.
• Ruby on Rails — выше порог входа для кастомизации. Штатные настройки (триггеры, поля, роли, SLA) делаются мышкой и доступны любому админу. Но если нужна глубокая доработка на уровне кода, Rails — это не PHP: специалиста под него найти сложнее и стоит он дороже, чем условного PHP-разработчика под osTicket. Для типовых внедрений это не проблема, потому что кода трогать не приходится; для сильно кастомных — фактор.
• Аппетит к ресурсам. Стек Rails + PostgreSQL + Redis + Elasticsearch — не лёгкий. Главный едок — Elasticsearch: он прожорлив к памяти, и на VPS с 2 ГБ система жить не будет — поиск ляжет первым. Нормальная инсталляция с поиском — это машина класса 4 ГБ минимум, а комфортно — 8 ГБ. Об этом подробно — в следующей статье серии про развёртывание.
• Нет нативного мобильного приложения агента. Zammad — это адаптивный веб: с телефона работать можно через браузер, интерфейс подстраивается, но отдельного приложения «Zammad для агента» в сторах нет. Для большинства команд это не проблема (агенты работают за компьютером), но если ваша поддержка живёт в разъездах с телефона — учитывайте.

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

Сравнительная таблица: Zammad vs GLPI vs osTicket vs российские SaaS

Свожу трёх open source-финалистов и обобщённый российский SaaS в одну таблицу — по тем критериям, которые реально влияют на выбор для фирмы до 50 рабочих мест. Оценки — из нашей практики внедрений, а не из рекламных материалов.

Вывод из таблицы удобно читать как матрицу «кому что подходит»:

• Нужен учёт техники плюс заявки в одной системе — GLPI. Это его родная территория: CMDB, инвентаризация, автоматический сбор данных о парке машин. Тикеты в нём тоже есть, но интерфейс поддержки суше, а Telegram и веб-чата из коробки нет.
• Нужно максимально просто и дёшево по железу — osTicket. Лёгкий LAMP-стек, поднимается на слабом VPS, ставится за час. Расплата — минимализм: ни встроенного Telegram, ни веб-чата, ни AI, локализация неполная. Для простой email-поддержки без изысков — рабочий вариант.
• Нужна поддержка клиентов с приятным интерфейсом, Telegram и веб-чатом — Zammad. Он лучший именно в общении с клиентом: каналы из коробки, живой интерфейс, который нравится агентам, полный русский, AI с локальной LLM. Платите за это аппетитом к железу и чуть более высоким порогом входа.
• Российский SaaS побеждает по скорости старта (ничего не разворачивать) и проигрывает по главному для многих критерию — данные лежат не у вас, и за это капает ежемесячная плата, растущая с числом агентов. На горизонте трёх лет self-hosted почти всегда выходит дешевле.

Вердикт: кому Zammad подходит, а кому нет

Соберу всё сказанное в короткий и честный вердикт.

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

Zammad — не ваш выбор, если вам нужен полноценный ITIL-комбайн с CMDB, учётом активов и управлением изменениями: это принципиально другой класс систем, и здесь честнее взять GLPI. Не стоит его брать и на совсем слабый сервер без запаса памяти — Elasticsearch не простит, — и если у вас нет никого, кто сопроводит Docker-стек, а бюджета на аутсорс сопровождения тоже нет.

Это была обзорная, вводная статья серии. Дальше мы спускаемся с уровня «что и зачем» на уровень «как руками»: следующий материал — «Разворачиваем Zammad 7.1 на своём VPS: Docker, Elasticsearch и грабли», где по шагам разбираем установку, сайзинг сервера и типовые ошибки. А за ним — «Zammad в бою: Telegram, почта, веб-чат и Active Directory» про подключение каналов и вход через доменные учётки. Все материалы блога — на странице «Все статьи блога АйТи Фреш».

А если тикет-система нужна работающей уже к следующей неделе и без экспериментов на живых клиентах — это ровно наша работа. Мы в ITfresh развернём Zammad под ключ на вашем или нашем сервере в дата-центре МТС, настроим каналы, SLA и русский интерфейс, прогоним по чек-листу сдачи и возьмём на сопровождение. Пишите в Telegram @ITfresh_Boss или звоните +7 903 729-62-41.