01
Приём заявок и статусы
Клиент оставляет обращение в закрытой части и видит его состояние — без звонка и без вопроса «ну что там». История остаётся в системе, а не в чужой переписке.
Все кейсы
Кейс
Система приёма заявок для обслуживания инженерных сетей
МКВ обслуживает инженерные сети. Мы сделали корпоративный сайт и закрытую часть, через которую клиент оставляет обращение и ведёт его до закрытия, не звоня диспетчеру по каждому поводу.
Задача
Заявка, которая живёт в телефонном звонке
Обслуживание инженерных сетей — это поток обращений, у каждого из которых есть адрес, срочность, исполнитель и срок. Пока такие обращения приходят звонками и сообщениями, у них нет ни статуса, ни истории: клиент не знает, что происходит с его задачей, а диспетчер тратит день на ответы «да, приняли, ждите».
Нужно было место, где обращение перестаёт быть разговором и становится записью, за которую кто-то отвечает.
Решение
Что работает на сайте
02
Переписка с диспетчером в реальном времени
Уточнения идут внутри самой заявки, а не отдельным каналом. Всё, что сказано по задаче, лежит рядом с задачей — включая то, что было сказано полгода назад.
03
Фотографии с объекта
Клиент прикладывает снимки прямо к обращению. Для инженерных сетей это экономит выезд: часто по фотографии видно, что именно случилось и какой специалист нужен.
04
Помощник на основе ИИ
Подсказывает категорию обращения по тексту. Человек, который пишет заявку, не обязан знать Вашу внутреннюю классификацию — а диспетчер получает уже разобранный поток.
05
Отдельный режим для государственных заказчиков
У работы с госорганизациями другой порядок и другие требования к документам. Это не настройка, а отдельная ветка сценария, продуманная заранее.
06
Витрина и закрытая часть вместе
Публичный сайт рассказывает о компании и приводит обращения, закрытая часть их обрабатывает. Это один проект, а не сайт плюс отдельная система с отдельным входом.
Почему так
Что здесь важнее красивой вёрстки
В системе, где есть вход и чужие данные, главное — кто что видит. Клиент должен видеть свои заявки и только свои; диспетчер — очередь; администратор — всё, и его действия должны быть записаны. Это разграничение прав на уровне отдельных записей, а не разделов, и закладывается оно на старте: переделать потом дороже, чем сделать сразу.
Такие проекты мы ведём как веб-сервис, а не как сайт: сайт показывает информацию, сервис выполняет работу.
Нужна такая же система заявок?
Расскажите, как обращения приходят сейчас и что в этом потоке теряется. Оценку и смету пришлём до начала работ.