Разработка портала для охранного предприятия

Разработка сайта для охранного предприятия: где теряются заявки

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

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

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

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

Что меняется после запуска портала: измеримые эффекты

Портал меняет не «удобство интерфейса», а распределение работы между людьми и системой. Ниже — четыре участка, где эффект виден по метрикам уже в первые месяцы работы.

Заявки без ручного ввода

Клиент оформляет заявку в кабинете или мобильном приложении, она сразу раскладывается по объекту, посту и смене. Диспетчер не переписывает данные из почты и мессенджеров — доля заявок, проходящих без ручного ввода, доходит до 9 из 10. Остальные помечаются как нестандартные с указанием причины, и это видно в отчёте.

Реакция на тревожное сообщение

Тревога с объекта встаёт в приоритетную очередь и всплывает у свободного оператора, а не ждёт обхода журнала. Событие фиксируется с меткой времени, эскалация срабатывает, если никто не взял его в работу за заданный интервал. Время реакции сокращается с минут до десятков секунд и перестаёт зависеть от загрузки смены.

График смен без наложений

Система проверяет пересечения, переработки и ситуацию, когда сотрудник стоит на двух постах одновременно, учитывает допуски и сроки удостоверений. График синхронизируется с 1С, поэтому расхождения между нарядом и учётом не накапливаются. Ошибки ловятся в момент публикации, а не при закрытии периода — их число падает в разы.

Класс отказов, который уходит

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

Форматы портала для охранного предприятия: витрина или кабинет

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

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

Этапы работы: от разбора процессов до передачи портала

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

1. Аудит процессов охраны — интервью с диспетчерами, начальниками смен, инженерами объектов; фиксируем маршруты обходов, регламент реагирования на тревогу, порядок закрытия смены. На выходе — карта процессов с точками, где данные теряются или дублируются.
2. Схема ролей и доступов — матрица «роль × объект × действие»: диспетчер видит только свои посты, руководитель направления — сводку по всем, клиент охраняемого объекта — статус заявок и отчёты.
3. Модель данных и интеграции — объекты, посты, наряды, сотрудники, техника, тревожные события. Определяем, что портал читает из действующей системы, а что ведёт сам, и как разрешаются конфликты при одновременном редактировании.
4. Сборка итерациями — каждые две недели рабочая версия на тестовом контуре: сначала справочники и права, затем наряды и графики смен, потом отчёты и мобильная часть для сменных сотрудников.
5. Проверка перед запуском на пилотной группе объектов: прогон сценариев тревоги, массового выхода смен, доступов с истёкшим сроком. Права каждой роли проходим вручную — так находятся дыры, которые не ловит автотест.
6. Обучение и передача — инструкции под каждую роль, схемы интеграций, регламент резервного копирования и восстановления, передача доступов и разбор типовых ошибок операторов.

Документация, схемы процессов и доступы: что передаём на руки

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

• Права доступа сотрудников — матрица «роль × раздел × действие»: что видит диспетчер, чем ограничен подрядчик на объекте, кто из руководителей выгружает отчёты и где заканчивается зона администратора.
• Регламент обработки заявок — порядок от приёма сигнала до закрытия: классификация, назначение наряда, подтверждение выезда, фиксация времени реакции на каждом шаге.
• Регламент по тревожным сообщениям — отдельная ветка с эскалацией по таймеру, правилами дублирования контактов и обязательной отметкой причины, если сигнал снят вручную.
• Схемы процессов — карта маршрутов заявки и тревоги в виде понятных блоков: видно, где документ теряется и какой шаг требует согласования.
• Инструкции для диспетчера — короткие сценарии под каждую частую ситуацию: новый объект, отмена выезда, некорректный адрес, жалоба клиента.
• Порядок резервного копирования — что и как часто сохраняется, где лежат копии, сколько времени занимает восстановление и кто отвечает за проверку.
• Передача доступов — список учётных записей с владельцами, способ выдачи и порядок закрытия при увольнении сотрудника.

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

Кейс: как убрали ручное распределение заявок между постами

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

Что было до внедрения портала

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

Что изменили и что получилось

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

• доля автоматических распределений: 0 → 94%;
• среднее время реакции на сигнал: 18 минут → 4 минуты;
• ручных операций за смену: 220 → 30;
• потерянных заявок за квартал: единичные случаи → ноль, у каждой тревоги полная история.

Диспетчеры перешли с раздачи заявок на контроль исключений — спорные адреса, нестандартные объекты, сбои связи.

Чем портал отличается от сайта с формой заявки

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

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

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

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

Граница проходит так: сайт с формой отвечает на вопрос «обращение получено?», портал — на вопрос «что сейчас с объектом и чем закончится смена». Поэтому выбор между порталом или сайтом с формой — это выбор между приёмом обращений и управлением охраной.

Технические вопросы, которые задают до старта проекта

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

Как портал свяжется с учётной системой и графиком смен?

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

У нас всё годами ведут в таблицах — данные перенесёте?

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

Кто ведёт портал после запуска?

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

Расскажите о процессах — вернёмся с планом и оценкой

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

Чтобы быстро обсудить разработку портала, пришлите:

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

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