Заявки теряются в почте, дублируются в Excel и всплывают через три дня после дедлайна - с такой проблемой ко мне чаще всего приходят за разработкой веб-приложения для управления заявками. За последние два года я собрал больше десятка подобных систем: от простого трекера на 200 обращений в месяц до сервиса с очередями, SLA-таймерами и интеграцией с СДЭК и эквайрингом. Разберу архитектуру, обязательный набор функций и на что смотреть при выборе стека, если планируете такую систему для своей команды.
Зачем компании отдельный сервис учёта заявок
Excel-таблица и почтовый ящик работают, пока заявок меньше 30-40 в месяц и обрабатывает их один человек. Как только подключается второй отдел или клиенты начинают писать в трёх каналах одновременно - в почту, в Telegram и через форму на сайте - начинаются потери: заявка провисает без ответа, два сотрудника берут одну и ту же в работу, руководитель не понимает, сколько обращений открыто прямо сейчас.
На практике порог, после которого клиент решает делать отдельную систему, - 100-150 заявок в месяц на команду от трёх человек. Ниже этой границы окупаемость разработки под вопросом, выше - таблица физически не справляется с контролем сроков и ответственных.
Отдельный сервис даёт то, что нельзя собрать в Excel: автоматическую маршрутизацию по отделам, SLA-таймеры с эскалацией, историю переписки по каждой заявке и отчётность по загрузке сотрудников за любой период.
Архитектура: из каких слоёв собрано приложение для обработки обращений
Любая система такого типа состоит из четырёх слоёв, и от того, как они связаны, зависит, переживёт ли приложение рост нагрузки в три-четыре раза.
Клиентская часть. Обычно это два интерфейса: панель для сотрудников (список заявок, фильтры, канбан-доска по статусам) и портал для клиентов, где можно завести обращение и посмотреть его статус. Собираю на React или Vue - оба варианта дают SPA без перезагрузки страницы при каждом действии.
API-слой. Backend принимает заявки из всех каналов через единый интерфейс, независимо от того, пришла заявка с формы на сайте, из письма или от Telegram-бота. Пример запроса на создание заявки через REST API:
curl -X POST https://api.example.com/tickets
-H "Authorization: Bearer $TOKEN"
-d '{"channel":"telegram","subject":"Не пришла посылка","priority":"high"}'Очереди и фоновые задачи. Отправка уведомлений, генерация отчётов, проверка просроченных SLA - всё это не должно тормозить основной запрос пользователя. Redis-очередь с воркерами разгружает API и держит время ответа в пределах 100-200 мс даже при 500+ заявках в очереди.
Хранилище. PostgreSQL для основных данных, Redis - для кэша и очередей, S3-совместимое хранилище - для вложений: скриншотов, сканов документов, файлов от клиентов.
Стек технологий: что выбираю под разные объёмы заявок
Стек подбираю не по личным предпочтениям, а по объёму заявок, числу каналов приёма и требованию к реальному времени. Ниже - четыре сценария, с которыми сталкивался на практике.
| Сценарий | Стек | Когда беру этот вариант |
|---|---|---|
| MVP-трекер для одного отдела, до 300 заявок/мес | React + Laravel + PostgreSQL | Нужен рабочий сервис за 5-6 недель без переусложнения |
| Несколько отделов, SLA и эскалация | React + WebSocket, Laravel/Node с очередями на Redis, PostgreSQL | Нужны уведомления в реальном времени и автоматическая маршрутизация |
| Заявки приходят с сайта на Tilda или WordPress | Tilda-скрипт / WooCommerce-хук на приём формы + отдельный API на Laravel | Сайт трогать не нужно, приём заявок добавляется поверх существующей витрины |
| Основной канал - Telegram (курьеры, сервисные заявки) | aiogram-бот + FastAPI/Laravel backend + PostgreSQL | Клиенты и исполнители общаются в мессенджере, веб-панель нужна только для контроля |
Для интернет-магазинов на WooCommerce часто заявки на возврат или разбор платежа приходят из связки с эквайрингом - в таких случаях подключаю систему заявок напрямую к вебхукам T‑Bank, чтобы статус оплаты автоматически проставлялся в карточке обращения, а не переносился вручную.
Бесплатный материал
🎁 Полезный скрипт в подарок
Подпишитесь на Telegram - пришлю готовый скрипт по этой теме.
Без спама. Отписка в 1 клик.
Функции, без которых тикет-система не работает
Набор функций, который встречается в 90% моих проектов, вне зависимости от отрасли:
- Приём заявок из нескольких каналов одновременно - форма на сайте, почта, Telegram, звонок с фиксацией в карточке
- Автоматический номер и статус при создании: новая → в работе → ожидает ответа → закрыта
- Маршрутизация по отделам и приоритету, ручная и по правилам
- SLA-таймеры с эскалацией ответственному или руководителю при просрочке
- История переписки и вложений в одной карточке, без переключения между почтой и мессенджером
- Уведомления в Telegram, email или push при смене статуса
- Ролевая модель: клиент видит свои заявки, сотрудник - заявки отдела, руководитель - всё и отчёты
- Отчёты по среднему времени ответа, загрузке сотрудников и количеству просрочек за период
Часть этих функций закрывается кодом за пару дней - статусы, история переписки. Часть требует отдельной проработки: SLA-таймеры с эскалацией и разграничение прав по ролям обычно занимают 30-40% времени разработки backend.
Интеграции: СДЭК, эквайринг, Telegram и n8n
Заявки редко существуют в вакууме - они почти всегда завязаны на соседние системы, и именно интеграции чаще всего определяют итоговую стоимость проекта.
СДЭК и доставка. Если заявка связана с отправкой или возвратом товара, подключаю API СДЭК: статус трек-номера подтягивается в карточку автоматически, и сотруднику не нужно вручную проверять его на сайте перевозчика. Похожие кастомные интеграции я собирал для клиентов на Tilda - часть готовых наработок по приёму заявок и связке с СДЭК лежит в библиотеке готовых скриптов, можно посмотреть, как устроена логика на стороне формы.
Эквайринг. Для магазинов на WooCommerce заявки на возврат средств завязываю на вебхуки T‑Bank - как только приходит статус возврата, заявка закрывается автоматически, без ручной сверки бухгалтером.
Telegram. aiogram-бот закрывает две задачи: приём новых заявок от клиентов и уведомления сотрудникам о новых обращениях или просрочке SLA прямо в рабочий чат - быстрее, чем проверять почту.
n8n. Когда правила маршрутизации меняются часто и нет ресурса переписывать backend под каждое изменение, выношу логику в n8n: заявка попадает по вебхуку, дальше сценарий сам решает, кому назначить и какое уведомление отправить. Для отдела поддержки из 5-7 человек такой подход экономит время на доработках правил в дальнейшем.
Сколько стоит разработка сервиса для управления обращениями
Финальная стоимость зависит от числа каналов приёма, глубины интеграций и того, нужен ли отдельный клиентский портал или хватит внутренней панели для сотрудников. Ориентируюсь на такие цифры по своим проектам:
- MVP веб-сервис под один отдел (SPA + backend + БД): от 300 000 ₽
- CRM/админ-панель с ролями, канбаном и отчётами на React: от 100 000 ₽
- Отдельный API/бэкенд, если фронтенд уже есть: от 100 000 ₽
- Telegram-бот как канал приёма и уведомлений: от 30 000 ₽
- Автоматизация маршрутизации и уведомлений в n8n: от 25 000 ₽
- Кастомная интеграция с СДЭК или эквайрингом: от 40 000 ₽
- Техподдержка и доработки после запуска: от 15 000 ₽/мес
На рынке студии просят за похожий функционал от 300 000 до 800 000 ₽ - это не мой прайс, а ориентир по тому, что видел у коллег и в отзывах клиентов, которые до меня уже проходили этот путь через агентство. Разница обычно объясняется числом менеджеров в проекте и накладными расходами студии, а не сложностью самой разработки.
Срок для MVP - 5-6 недель, для системы с SLA, ролями и двумя-тремя интеграциями - 10-14 недель.
Когда нужен не сайт, а сервис
SaaS / SPA
от 300 000 ₽
Подробнее →Частые вопросы
Чем веб-приложение для управления заявками отличается от готового хелпдеска вроде Zendesk?
Готовый хелпдеск быстрее запустить - учётка и первые настройки за день. Но он рассчитан на типовой процесс: если у вас нестандартная маршрутизация, специфичные статусы или заявка должна дёргать СДЭК и эквайринг одновременно, начинаются доработки через API хелпдеска, которые по стоимости за год-два догоняют кастомную разработку. Подписка на такой сервис для команды из 10 человек на рынке обходится в 40 000-60 000 ₽ в месяц - это тоже не мой прайс, а рыночная цена подписки. Свой сервис через 2-3 года выходит дешевле и точнее ложится на процессы.
Сколько времени занимает разработка такой системы?
MVP с одним каналом приёма и базовыми статусами - 5-6 недель. Система с SLA-таймерами, ролевой моделью и интеграцией с СДЭК или эквайрингом - 10-14 недель. Срок увеличивается, если нужен отдельный клиентский портал с личным кабинетом - добавляю ещё 3-4 недели.
Можно ли встроить приём заявок в существующий сайт на Tilda или WordPress?
Да, и переписывать сайт для этого не нужно. На Tilda ставлю кастомный скрипт на форму, который отправляет данные в API системы заявок, - простая доработка такого рода стоит от 3 000 ₽, комплексная интеграция с проверкой статусов и вебхуками - от 40 000 ₽. На WordPress и WooCommerce работаю через хуки плагина или темы, без переноса сайта на другую платформу.
Нужна ли отдельная мобильная версия?
В большинстве проектов хватает адаптивной веб-панели - сотрудники открывают её с телефона через браузер, этого достаточно для просмотра заявок и смены статуса. Отдельное мобильное приложение имеет смысл, если исполнители работают в поле без стабильного интернета и нужна офлайн-синхронизация, - такие кейсы у меня были у сервисов с выездными курьерами.