В клининге, ремонте, обслуживании, в сети точек проблема одна и та же. Сотрудник на месте видит неисправность и говорит о ней по телефону. Сказал - и забыл. Никто не записал, кому передали, сделали или нет. Через неделю выясняется, что лампу так и не заменили. Сообщение о потёке в подсобке потерялось в переписке. QR-код меняет точку входа: человек у самого места проблемы сканирует код, заполняет короткую форму, и просьба становится заявкой с номером, местом и ответственным. Разбираем, как устроить такой канал. Общий подход к таким системам у нас собран в разделе проектов.
Почему заявки теряются в звонках и чатах?
Коротко: звонок и общий чат не оставляют записи. Заявка живёт в чужой памяти, поэтому часть обращений просто исчезает.
Звонок не оставляет следа. Нет записи, кто принял, что именно просили и когда обещали сделать. Чат в мессенджере чуть лучше, но и он утопает: за день в общем чате десятки сообщений, и заявка на ремонт стоит между «кто-нибудь видел ключи» и фотографией кота. Через месяц никто не скажет, сколько обращений было, сколько закрыли, сколько висят. При этом сам исполнитель часто не виноват: ему просто не передали адрес и суть. Пока нет отдельной записи на каждое обращение, вся очередь живёт в чужой памяти.
Как выглядит путь заявки от QR до исполнителя?
Коротко: код на месте, короткая форма, место подставляется само, заявка попадает в очередь с ответственным. Пропуск любого шага возвращает потери.
Маршрут короткий, и в нём важны все четыре шага. Пропущенный шаг - и заявка снова теряется, только уже в новой системе.
- QR-код на месте. Свой код на каждое место: щиток, помещение, единица оборудования. Тогда место известно заранее, и человек его не описывает словами.
- Короткая форма в браузере. Открывается по ссылке из кода. Ставить приложение не нужно, вход по номеру телефона тоже лишний.
- Место подставляется само. Из кода видно, какой объект и какое место. Человек только описывает, что не так, и при желании добавляет фото.
- Очередь с ответственным. Заявка попадает туда, где её видит исполнитель: с номером, статусом и уведомлением.
Смысл в том, что заявка перестаёт быть сообщением. У неё есть место, автор, время и статус.
Что должно быть в форме, чтобы заявку можно было выполнить?
Коротко: чем меньше обязательных полей, тем чаще заполняют форму. Место берётся из кода, обязательных полей два - что случилось и как связаться.
Форма работает по простому правилу: чем меньше обязательных полей, тем чаще её заполняют. Человек у щитка не станет заполнять анкету.
Правило первое: место не спрашивать. Оно уже известно из QR-кода. Если код на объекте один, а мест много, предложите выбрать место из короткого списка, а не вводить руками.
Правило второе: обязательных полей - два. Что случилось и как с вами связаться. Фотографию оставьте по желанию: она помогает исполнителю, но требовать её нельзя, иначе часть людей просто закроет форму.
Правило третье: не спрашивайте телефон отдельно, если человек и так вошёл в систему. Разделы вроде «категория», «приоритет» и «вид работ» лучше не отдавать заявителю: категорию определит диспетчер, а приоритет по описанию виден и так. Лишние поля удлиняют форму и превращают заявку в маленькое заявление, дочитав до которого человек передумает.
Куда складывать заявки: чат, CRM или своя очередь?
Коротко: выбор зависит от того, кто разбирает обращения и связаны ли они с клиентами. Общий чат годится только для пары заявок в неделю.
На выбор влияет то, кто и как быстро разбирает обращения.
| Куда попадают заявки | Когда подходит | Чем расплачиваетесь |
|---|---|---|
| Общий чат | Один объект, пара заявок в неделю | Теряются в переписке, нет статуса и ответственного |
| CRM или service desk | Есть отдел, который ведёт обращения, и нужен учёт по клиентам | Полей и статусов больше, чем нужно простой заявке, настройка дольше |
| Отдельная очередь заявок | Заявки с объектов - это отдельный поток, не связанный с продажами | Нужна связка с учётом, если данные должны идти дальше |
Если заявки с объекта никак не связаны с продажами и клиентами, отдельная очередь часто удобнее: она проще и не тонет в карточках сделок. Когда же обращения нужно видеть рядом с историей клиента, разумнее сразу складывать их в CRM. Так сеть офлайн-центров проектировала устройство системы заранее, до начала разработки.
Что даёт QR-канал и чего от него не ждать?
Коротко: канал даёт порядок и историю по каждому месту. Быстрее работать исполнителя он не заставит и аварийный звонок не заменит.
Канал даёт порядок: поток обращений не теряется, у каждой заявки есть номер, место, автор и ответственный, видно время от подачи до закрытия. Появляется история по каждому месту: сколько раз ломалось, что чинили, как долго. Это уже основа для решений, а не догадок.
Чего не будет. Он не заставит исполнителя работать быстрее, если тот не спешит. Он не заменяет аварийный звонок: прорвало трубу - звонят, а не сканируют код. И он не поможет там, где заявок слишком мало для отдельной системы. Иногда честный итог разбора - что заказчику достаточно доски в подсобке и тетради, и это тоже результат.
Что ломается чаще всего?
Коротко: код содран или ведёт не туда, форма слишком длинная, у заявки нет ответственного и статуса.
- Код содран, переклеен или ведёт не туда. Регулярная проверка кодов - часть работы, а не разовая наклейка.
- Форма оказалась длинной, и люди перестали ею пользоваться. Вернулись к звонкам.
- У заявки нет ответственного. Её видят все и никто.
- Нет статуса. Заявку подали, а узнать, что с ней, нельзя.
- Один код на весь объект, и исполнитель не понимает, куда ехать.
Как принять такую систему?
Коротко: запустите на одном объекте и проживите неделю на настоящих обращениях. Приёмка - это когда ни одна заявка не осталась без ответственного.
Приёмка отвечает на один вопрос: теряются заявки или нет. Того, что форма открывается, для сдачи мало.
- Запустите на одном объекте. Не на всей сети сразу.
- Дайте поработать неделю на настоящих обращениях, а не на тестовых.
- Пройдите по каждой заявке и убедитесь, что у неё есть ответственный и статус.
- Смоделируйте сбой: уберите исполнителя из очереди и посмотрите, заметит ли кто-то, что заявка висит.
- Проверьте уведомления: приходит ли исполнителю сообщение о новой заявке.
- Отсканируйте код обычным телефоном с улицы и убедитесь, что он открывается без приложения.
Когда QR не нужен?
Коротко: при одном объекте и паре заявок в неделю система не нужна. Срочные случаи всё равно решает звонок.
Если объект один, заявок пара в неделю и их разбирает один человек, заводить систему незачем: хватит общего списка. Не нужен QR и для срочных случаев: прорыв, пожар, угроза людям - это звонок. Отдельная очередь оправдана, когда обращений становится столько, что память перестаёт их держать. Иногда ту же задачу закрывает отчёт поверх одной системы, и тогда до стройки дело не доходит. Как мы смотрим, нужна ли вообще автоматизация, разбирается отдельно.
Источники
- ISO/IEC 20000-1 - управление ИТ-услугами и запросы на обслуживание: ISO/IEC 20000-1
- Nielsen Norman Group, «Website Forms Usability» - почему длинные формы теряют заполняющих: Website Forms Usability
- GOV.UK Design System, «Text input» - как описывать поля и подсказки: Text input
- W3C, WCAG 2.2, «Error Identification» - как форма сообщает о проблеме в поле: Error Identification
- Material Design, «Text fields» - состояния поля и подсказки внутри формы: Text fields
Если обращения с объектов теряются, начните с маршрута заявки: опишите, кто и в какой момент её видит. Пришлите эту картину, и мы вернёмся с составом работ и сметой за 24 часа.