Аутстаффинговая компания вела подбор внешних IT-специалистов в почте и чатах: потребности заказчиков рассылались партнёрам текстом, отклики возвращались письмами. Мы перенесли цикл «потребность → публикация → отклик» в Telegram — с ролевой моделью, структурированной карточкой вакансии вместо свободного текста, статусами и автоматической маршрутизацией откликов. Бот двусторонне синхронизирован с ATS FriendWork Recruiter, поверх развёрнут веб-контур с той же авторизацией и ролями.
Что было сломано
Ключевой актив компании — поток потребностей — жил в переписке. Отсюда четыре системные проблемы:
Нет единого списка открытых потребностей
Актуальный срез существовал только в почте и в голове менеджера.
Требования неструктурированы
Вакансия — абзац прозой. Одну и ту же позицию два менеджера описывали по-разному: сравнивать, искать и считать невозможно.
Отклики теряются
Резюме приходили ответными письмами разным людям, связка «отклик → вакансия» держалась вручную.
Каждое изменение статуса — рассылка
Закрытая позиция продолжала собирать отклики, пока об этом не оповестили всех партнёров.
Цена проблемы — время менеджеров на диспетчеризацию писем и потерянные отклики партнёров по позициям, которые уже закрыты или, наоборот, всё ещё открыты.
Что построили
Двусторонняя биржа в Telegram: с одной стороны заводят потребности, с другой приходят отклики. Мессенджер выбран как среда, в которой рекрутеры и партнёры уже работают, — это снимает онбординг и логины, главный барьер внедрения любого внутреннего портала.
Ролевая модель, 4 роли
Менеджер ведёт потребности и видит отклики; партнёр видит открытые потребности и присылает кандидатов; модератор отвечает за качество карточек; администратор управляет ролями. Роли назначаются командой внутри бота — без участия разработчика. Свои текущие роли пользователь видит прямо в справке, поэтому вопрос «а что мне доступно» не возникает.
Карточка вакансии из 13 полей вместо текста
Наименование (собирается системой из категории, компетенции и грейда), ID, опыт, регион, формат работы, проект, задачи, требования, оборудование, срок проекта, схема отбора, контакт, статус. Заголовок вакансии формируется из полей автоматически и выходит единообразным у всех менеджеров.
Каскадный ввод кнопками
Ключевые поля не набираются, а выбираются по цепочке: категория специалиста → компетенция → грейд → подтверждение. У части категорий собственные справочники грейдов, отличные от общего. На каждом шаге доступны «Другое» и «Назад».
Жизненный цикл вакансии
Статусы вместо удаления: открыта → закрыта → переоткрыта. Закрытая уходит из выдачи и перестаёт принимать отклики, но сохраняется: заказчик возвращается с той же ролью через месяц — позиция поднимается одной кнопкой вместе со всей историей.
Двусторонняя синхронизация с ATS
Бот интегрирован с FriendWork Recruiter — облачной ATS, на которой у клиента держится найм. Обмен идёт в обе стороны: заведённые в боте потребности и пришедшие отклики попадают в систему подбора, изменения на стороне ATS возвращаются в бота. Telegram становится каналом ввода и распространения, а не ещё одной параллельной базой — иначе через месяц у компании было бы два расходящихся списка вакансий.
Веб-контур поверх бота
Авторизация через Telegram и та же ролевая модель: там, где боту тесно — таблицы, отчётность, массовые операции, — работа продолжается в браузере под той же учётной записью.
На чём всё держится
- Схема данных важнее интерфейса. Основная работа проекта — не диалог, а справочники и структура карточки: поиск, статусы и история появились как следствие структуры, а не как отдельные функции.
- Конечный автомат диалога. Каскадный ввод требует хранить позицию пользователя в цепочке, накопленный выбор и возможность отката на шаг назад без потери остального. Самая трудоёмкая часть системы — и она же даёт качество данных на входе.
- Мультивыбор там, где реальность неоднозначна. Грейд и регион — множественный выбор: рынок редко хочет строго одного Senior строго в Москве.
- ATS остаётся системой-источником. Бот не заводит собственную параллельную правду о найме, а синхронизируется с ней в обе стороны.
Чем пожертвовали и ради чего
| Решение | Цена | Почему так |
|---|---|---|
| Кнопки вместо свободного ввода | Ввод медленнее, чем «скопировал письмо» | Иначе данные снова становятся текстом и весь смысл системы теряется |
| Ветка «Другое» на каждом шаге | Часть записей вне справочника, нужна доразметка | Без клапана справочник блокирует нестандартный спрос |
| Отдельные справочники грейдов под категории | Нельзя обойтись одной таблицей | У SAP-направления своя грейдовая шкала — общая была бы неправдой |
| Статусы вместо удаления | База растёт, нужен фильтр по умолчанию | История и переоткрытие позиции важнее компактности |
| Telegram как основной интерфейс | Ограничения UI мессенджера | Нулевой онбординг для внешних партнёров, которых не заставить завести аккаунт в портале |
Как шли
Ядро и роли
Регистрация, ролевая модель, справка с ролями, базовые команды.
Публикация и поиск
Карточка вакансии, каскадный ввод, выдача открытых потребностей, фильтр по заказчику, смена статусов.
Отклики
Пошаговый сценарий отклика, маршрутизация в общий канал команды, привязка к вакансии.
Интеграция и веб-контур
Двусторонний обмен с ATS, авторизация через Telegram, перенос ролей, разделы для отчётности.
Что изменилось
- Цикл «потребность → публикация → отклик» полностью ушёл из почты в мессенджер.
- У партнёров появился один общий список открытых потребностей вместо адресных рассылок.
- Отклики собираются в одну точку с привязкой к вакансии и попадают в ATS без ручного переноса.
- Система осталась в эксплуатации на годы после сдачи и развивалась дальше — при сроке разработки в полтора месяца part-time.
Операционные показатели — число партнёров, пользователей и вакансий — клиент не раскрывает. Приведено только то, что подтверждается артефактами проекта.
Как это выглядело
Инженерный контекст
Проект сделан в 2022 году, до появления доступных языковых моделей. Разбор требований на поля, единообразие заголовков и поиск специалиста решались справочниками, конечным автоматом и схемой данных — теми средствами, которые были.
Сегодня слой ввода мы бы сняли моделью: вакансия заводится пересланным письмом или голосом, модель раскладывает её по полям и уточняет только недостающее, а поиск идёт по смыслу, а не по совпадению справочника. Что не меняется — под диалогом по-прежнему должна лежать строгая схема данных: без неё не работают ни поиск, ни статусы, ни выгрузка в смежные системы. LLM ускоряет ввод, но не отменяет проектирование модели данных.
Кейс обезличен по соглашению о конфиденциальности: клиент и его заказчики не раскрываются. На скриншотах — интерфейс разработанного решения.