Кейс: как мы внедрили Zammad в юрфирме на 30 сотрудников — от хаоса в почте до SLA по договорам за две недели

Исходная точка: ящик info@, личные телефоны и стикеры

Меня зовут Евгений Семёнов, я технический директор ITfresh. Мы пятнадцать с лишним лет занимаемся IT-аутсорсингом для московских компаний до пятидесяти рабочих мест, свои серверы держим в дата-центре МТС. Юридические фирмы — один из постоянных профилей, и приходят они к нам, как под копирку, с одной и той же картиной. Покажу её на примере конторы, с которой мы прошли путь от хаоса до работающего SLA за две недели.

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

Как жили обращения. Общий ящик info@, в который смотрели «все и никто»: формально — два секретаря, фактически — кто вспомнил. Заметная часть доверителей писала не туда, а напрямую юристу в личный WhatsApp, потому что «так быстрее отвечает». Устные просьбы превращались в стикеры на мониторах. Передача дел на время отпуска выглядела как пересылка пачки писем и скриншоты переписки с телефона.

Перед стартом мы сделали замер «до»: выгрузили из info@ месяц переписки и посчитали руками. Медиана времени первого ответа вышла больше 26 часов. Хуже того — на семь писем из выборки ответа не нашлось вообще, ни в ящике, ни в отправленных. А по WhatsApp статистики нет в принципе: это личные телефоны, фирма их не видит и не контролирует.

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

Почему не облачный SaaS

Первым предложением младшего партнёра было «взять облачный хелпдеск по подписке, там всё готово». Мы честно разобрали этот вариант — и он не прошёл по трём причинам, причём деньги оказались лишь третьей.

Первая — адвокатская тайна и конфиденциальность. В обращениях доверителей лежит всё: суть корпоративных споров, суммы сделок, персональные данные сотрудников и контрагентов. Юрфирма — оператор персональных данных по 152-ФЗ, а поверх этого связана профессиональной тайной. Выносить такую переписку в чужое облако, где фирма не контролирует ни физическое размещение данных, ни круг лиц с доступом, партнёры отказались сразу. Я с ними согласен: своя инсталляция на своём сервере закрывает вопрос по существу — данные лежат там, где вы решили, и доступ к ним только у вас.

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

Третья — бюджет. Мы посчитали стоимость владения для восьми агентов (столько сотрудников реально работает с обращениями) на горизонте трёх лет. Цифры округлены, но пропорция из проекта в проект повторяется.

Да, свой вариант дороже на старте: за внедрение платят один раз человеку, а не помесячно платформе. Но уже со второго года эксплуатация стоит только аренды VPS и сопровождения, и разрыв растёт с каждым нанятым юристом — в подписочной модели каждый новый агент стоит денег, в Zammad — нет.

Требования и выбор: почему именно Zammad

Требования уместились на одной странице, и я советую любой фирме начинать именно с такого списка, а не с обзора продуктов:

• Единое окно. Почта, сайт, мессенджер — всё падает в одну очередь, ничего не живёт в личных телефонах.
• История по организации-доверителю. Открыл карточку компании — видишь все обращения всех её сотрудников за годы.
• SLA по типам договоров. Абонентский клиент и разовое поручение — разные обещания по срокам, система должна их различать и контролировать.
• Telegram как канал. Доверители уже там, заставлять их писать письма — терять обращения.
• Русский интерфейс из коробки и свой сервер — по причинам из предыдущего раздела.

Шорт-лист из мира open source получился из трёх систем: Zammad, GLPI и osTicket. GLPI мы любим и регулярно внедряем — кейс с бухгалтерской фирмой есть в этом же блоге. Но GLPI силён как ITSM-комбайн с инвентаризацией и учётом активов, а юрфирме CMDB попросту не нужна: считать три принтера незачем, зато критичны каналы и то, как система выглядит для клиента. osTicket лёгок и заслуженно живуч, но интерфейс у него родом из прошлого десятилетия, а с каналами скромно. Zammad выиграл по трём пунктам: современный интерфейс, который юристы приняли без сопротивления; штатные каналы — email, веб-форма, веб-чат, Telegram; аккуратный клиентский портал, где доверитель сам видит статусы своих обращений.

Пара слов о технике для тех, кто будет разворачивать. Zammad — это Ruby on Rails поверх PostgreSQL, рядом живут Redis и Elasticsearch (на нём построен быстрый поиск по всей переписке). Лицензия AGPLv3: self-hosted вариант бесплатен, без ограничений на число агентов и тикетов. На момент проекта актуальной была ветка 7.1, вышедшая в июне 2026-го; показательно, что уже 25 июня проект выпустил security-релиз 7.1.1 — с безопасностью здесь не тянут, и это важный аргумент для конторы, живущей на профессиональной тайне.

Неделя 1: сервер, каналы, импорт

Дни 1–2 — инфраструктура. VPS на 4 vCPU и 8 ГБ памяти: Elasticsearch прожорлив, на 4 ГБ Zammad формально запустится, но жить с ним будет грустно. Развернули стек через docker-compose из официального дистрибутива, повесили HTTPS с автопродлением сертификата, закрыли админку по IP. Бэкапы настроили в первый же день, а не «потом»: ночной дамп PostgreSQL плюс копия тома с вложениями уезжают на отдельное хранилище.

# /etc/cron.d/zammad-backup — ночной дамп БД, хранение 30 дней
30 2 * * * root docker exec zammad-postgresql-1 pg_dump -U zammad zammad | gzip > /backup/zammad-$(date +\%F).sql.gz
50 2 * * * root find /backup -name 'zammad-*.sql.gz' -mtime +30 -delete

День 3 — почта. Завели отдельный ящик support@ и подключили его почтовым каналом: Zammad забирает входящие, каждое письмо становится тикетом, ответы агентов уходят от имени этого же адреса. Старый info@ переключили пересылкой на support@ — адрес на визитках и в договорах продолжает работать, но письма больше не оседают в ничьём ящике. Туда же импортировали архив переписки за последний год, чтобы история клиентов не началась с чистого листа.

День 4 — Telegram и веб-форма. Бот создаётся у BotFather за две минуты, токен вставляется в штатный канал Telegram в админке — сообщения боту становятся тикетами, ответ юриста уходит человеку в тот же чат. Веб-форму «Задать вопрос» встроили на сайт готовым сниппетом из настроек Zammad.

День 5 — организации и контакты. Выгрузили из 1С и таблиц секретариата список доверителей — около сорока организаций и сто двадцать контактных лиц — и загрузили через CSV-импорт. Каждый контакт привязан к своей организации, поэтому письмо любого сотрудника доверителя автоматически ложится в историю его компании. Это та самая функция, ради которой всё затевалось: карточка организации стала досье.

Неделя 2: SLA по договорам, группы, шаблоны

Вторая неделя — не про технику, а про бизнес-логику. Начали с главного: перевели обещания из абонентских договоров в машинно-контролируемый вид. Получилась матрица из трёх уровней.

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

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

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

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

Пять триггеров, которые работают вместо дежурного

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

1. Автоназначение по домену отправителя. Письмо с домена доверителя сразу уходит в нужную практику и на ведущего юриста этой организации. Секретариат такие тикеты уже не триажит — маршрут известен заранее.
2. Эскалация партнёру. Если абонентский тикет провисел без первого ответа 80% срока SLA, уведомление получает управляющий партнёр практики. До нарушения обещания клиенту ещё есть время, но лампочка уже горит у того, кто может надавить.
3. Авто-тег «суд» и повышенный приоритет. Ключевые слова — «иск», «заседание», «апелляция», «повестка» — вешают на тикет тег и поднимают приоритет. Процессуальные сроки не прощают, и такие обращения не имеют права стоять в общей очереди.
4. Напоминание о молчании. Открытый тикет без ответа агента 24 часа — напоминание исполнителю и копия руководителю группы. Ловит классическую ситуацию «прочитал, решил ответить позже, забыл».
5. Еженедельная сводка партнёрам. Каждый понедельник партнёры получают отчёт: сколько открыто, закрыто, где просрочки. Управление сервисом перестало опираться на ощущения.

Сопротивление сотрудников: две недели дипломатии

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

Юристы продолжали отвечать с личной почты и из WhatsApp. Привычка плюс искреннее «клиенту так удобнее». Лечение оказалось двухходовым. Техническая часть — рабочие ящики юристов подключили к Zammad, чтобы даже письмо, отправленное клиентом лично юристу, попадало в систему. Организационная — управляющие партнёры на общем собрании ввели правило, которое я с тех пор советую всем: «чего нет в тикете — того не существует». Работа, не отражённая в системе, не считается сделанной; при споре с доверителем фирма защищает юриста только тем, что зафиксировано. После первой же спорной ситуации, где переписка в тикете спасла позицию фирмы, вопрос закрылся.

Секретариат боялся. Слова «тикет», «эскалация» и «триаж» звучали как экзамен. Хватило одного часового тренинга на живых примерах и шпаргалки на один лист: три кнопки, два правила. Через неделю секретари разбирали очередь быстрее, чем раньше открывали почту, — потому что система сама подсказывает, что горит.

Главный скептик — старший юрист судебной практики с двадцатилетним стажем и позицией «я всю жизнь работаю в почте, не мешайте». Мы не спорили, просто попросили месяц пожить по правилам. Через месяц он стал самым активным пользователем поиска: перед заседанием поднимает всю историю по доверителю за пару минут — вместо археологических раскопок по ящику и телефону. Теперь именно он объясняет новичкам, зачем нужна система. Лучшего амбассадора не придумаешь.

Результаты через три месяца

Через квартал после запуска мы сели с партнёрами и сравнили цифры — не ощущения «вроде стало лучше», а замер «до» против отчётов Zammad.

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

Отдельно про звонки «что с моим вопросом». Их поток упал не потому, что клиенты стали терпеливее, — они видят статус сами в клиентском портале и получают автоматические уведомления при смене состояния. Секретариат оценил это сильнее всех: раньше такие звонки съедали, по ощущениям, час в день.

Что бы мы сделали иначе

Кейсов без ошибок не бывает, а кейсы, где их скрывают, не стоят чтения. Четыре вещи мы сегодня сделали бы по-другому.

• База знаний — с первого дня, а не «когда-нибудь». Мы отложили её наполнение на «после запуска», и оно, конечно, не случилось само. В итоге секретариат первые два месяца задавал юристам одни и те же вопросы, которые могла бы закрывать статья. Сейчас мы закладываем в план внедрения два часа на десять стартовых статей — окупается в первую же неделю.
• Двоевластие ящиков затянулось. Мы месяц держали параллельно старую схему «кто-то смотрит info@ напрямую» и новую. Это худший из миров: люди не понимают, какой канал главный. Правильный срок переходного периода — две недели максимум, дальше старую дверь надо закрывать.
• Двухфакторную аутентификацию — сразу. Мы включили 2FA агентам через месяц, после того как в логах увидели перебор паролей к учётке одного из юристов с чужих адресов. Обошлось, но осадок остался: система с перепиской под профессиональной тайной обязана стартовать с 2FA, а не приходить к ней после инцидента.
• Недооценили вложения. Юристы прикладывают к тикетам сканы дел десятками мегабайт, и диск VPS кончился раньше прогноза — расширяли через два месяца. Теперь при расчёте под юрфирму мы сразу закладываем рост хранилища от вложений как отдельную строку, а не как «запас на всякий случай».

Переносимость шаблона: клиника и бухфирма

Ядро этого внедрения — каналы в одно окно, организации с историей, SLA по типу договора, пять триггеров — переносится между отраслями почти без изменений. Меняется обвязка, и вот два примера из нашей практики.

Медицинская клиника

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

Бухгалтерская фирма

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

Чек-лист самопроверки

Шесть вопросов, по которым я предлагаю проверить свою компанию — независимо от отрасли:

1. Можете ли вы прямо сейчас, за минуту, сказать, сколько обращений клиентов висит без ответа?
2. Есть ли переписка с клиентами, которая живёт только в личных телефонах сотрудников?
3. Что случится с историей клиента, если его ведущий менеджер завтра уволится?
4. Знаете ли вы медиану времени первого ответа — не «примерно», а по замеру?
5. Обещаны ли клиентам сроки реакции в договорах — и умеет ли кто-то их контролировать автоматически?
6. Где физически лежит переписка с клиентами — и устроит ли этот ответ самих клиентов?

Если хотя бы два ответа вам не понравились — у вас та же болезнь, что была у героев этого кейса. Хорошая новость: лечится она за две недели, недорого и по отработанному плану. Плохая новость только одна: каждое потерянное за это время письмо может стоить как весь проект.