Заявка: путь от «новой» до «закрытой»

Заявка — то, во что превращается любое обращение: звонок, письмо

или запись, заведённая руками. Дальше работа идёт только в ней.

Номер и фирма

Номер показывается с префиксом фирмы — например, ROM-000042.

Это удобно, когда инженер работает с десятком клиентов сразу:

по номеру сразу видно, чей он, и в разговоре его не спутать.

Статусы

Новая → В работе → Решена → Закрыта. Плюс

Ожидание клиента, когда работа стоит не по вашей вине.

Пока исполнителя нет, заявка висит в свободных — её видят все

инженеры, которые обслуживают эту фирму. Взять заявку — значит

назначить себя исполнителем.

Переходы между статусами разрешены не любые: систему нельзя

привести в состояние «закрыта, но никто не работал». Какие переходы

доступны сейчас, видно в самой заявке — гадать не нужно.

«Решена» и «закрыта» — не одно и то же

Решена — работа сделана, ждём подтверждения клиента.

Закрыта — вопрос исчерпан.

Разница не формальная: пока заявка «решена», клиент ещё может

сказать «не помогло». После решения ему уходит короткий опрос —

помогло или нет и оценка; ответ виден в заявке и собирается

в статистику качества.

«Что сделали»

При переводе в «Решена» система просит описать результат.

Черновик подставляется из последнего публичного комментария

инженера — часто достаточно проверить и подтвердить.

Это описание работает трижды: его видит клиент, оно ложится

в основу карточки для базы решений, и оно же

выручает, когда через полгода та же проблема повторится у другого

инженера.

Окно завершения одно на все точки входа — свайп по строке в списке,

кнопка в карточке, массовые действия по нескольким заявкам сразу.

Публичный комментарий и внутренняя заметка

Публичный комментарий уходит клиенту — письмом в переписку,

если обращение пришло с почты, или в Telegram.

Внутренняя заметка видна только вашим сотрудникам: она

не попадает в переписку, не порождает уведомлений клиенту

и отсекается ещё при выборке данных, а не прячется на экране.

Обсуждать в ней можно что угодно — наружу не уйдёт.

Объединение дублей

Один сбой часто приходит несколько раз: позвонили, написали,

и коллега пожаловался. Такие заявки объединяют, и присоединённая

при этом не удаляется:

обращение человека не пропадает;

от своего создания до решения главной. Клиент ждал с момента

своего обращения, а не с момента, когда вы решили объединить.

Объединение отменяется: комментарии вернутся туда, откуда пришли.

Обращения и инциденты

В статистике это два разных числа. Обращения — все заявки,

включая присоединённые: столько раз к вам обратились.

Инциденты — только главные: столько было разных проблем.

Разница между ними показывает, как часто одна поломка порождает

несколько обращений. Почему оба ответа верны и для каких вопросов

годится каждый, разобрано в статье [Восемь обращений по одному

инциденту](/vosem-obrashcheniy).

Сигнал массовой проблемы

Когда у клиента что-то падает, люди звонят один за другим, заявки

заводят разные инженеры, и никто не видит, что проблема одна.

Система следит за этим по трём признакам сразу: подряд идущие

звонки (быстро, но грубо), новые заявки (медленнее, точнее)

и расшифровки разговоров (ещё позже, зато надёжнее). Из них

собирается сигнал, который виден инженерам как карточка.

Слова «авария» в нём нет. Три обращения могут совпасть

случайно, а у большой фирмы это будни. Система показывает факты —

вывод делает человек.

Правила: что подставить в заявку из звонка

Заявка заводится по каждому разобранному разговору — это правило

без исключений, обращение не должно потеряться. А вот **чем она

будет заполнена**, настраивается: правила смотрят на номер

звонившего, категорию и теги разговора и подставляют приоритет,

исполнителя и категорию заявки. Срабатывает первое подходящее

правило.

Правило без единого условия не срабатывает вовсе — иначе оно

применялось бы к каждому звонку подряд, включая спам.