Сервис — это работа с обращениями: заявки, сроки, очереди, база знаний, портал для клиента. Здесь особенно важно ничего не потерять и не соврать в отчёте: клиент ждёт ответа, а руководителю нужно видеть, где сервис буксует. Продукт ведёт эту работу строго и честно, а вы наблюдаете и командуете.
Единая модель заявки
Заявка — это обращение, по которому нужна работа: починить, настроить, ответить, разобраться. Как и в коммуникациях, канал здесь — лишь свойство: письмо, форма на сайте, чат, звонок, портал — всё превращается в заявку одного вида. А «дверь», через которую обращение попадает в сервис, — настройка: можно задать, что письма на такой-то адрес становятся заявками, а письма на другой — обычной перепиской.
У заявки понятный жизненный путь: новая, в работе, ждём клиента, ждём внутри, решена, закрыта. Из закрытой можно вернуть, если проблема вернулась, — и это будет видно.
Заявка и диалог
Заявка и переписка связаны, но не дублируют друг друга. Обращение остаётся диалогом, а работа по нему — заявкой со сроками и ответственным. В карточке заявки видно саму переписку, а в диалоге — что по этому обращению заведена заявка. Благодаря этому клиенту не приходится повторять историю, а сотруднику не нужно сверять два списка.
Очереди, маршрутизация и назначение
Заявки раскладываются по очередям — по темам, по клиентам, по срочности. Правила распределения настраиваются как данные: «заявки про оборудование — этой группе», «срочные — дежурному». Всегда есть один ответственный и одна очередь — это правило не нарушается, поэтому не бывает заявок «между всеми». Если заявку перенаправили или передали, остаётся запись: кто, когда, из какой очереди в какую и почему. Правила распределения можно проверить «на сухую»: продукт скажет, кому уйдёт заявка, и покажет, почему именно ему.
Классификация
У заявки можно указать тип и категорию — это помогает и в отчётах, и в работе. Но тут важное правило: неклассифицированная заявка — это нормально. Не нужно придумывать категорию наугад, чтобы «закрыть поле»: неизвестное так и остаётся неизвестным, а подсказки можно дать позже. Списки типов и категорий защищены от случайного удаления — по ним считается статистика.
Есть и подсказка для сотрудника: продукт предлагает возможную категорию и приоритет, объясняя, на чём основано предложение. Решение всё равно принимает человек — подсказка только экономит время.
Внутренние и публичные сообщения
В заявке два вида сообщений: те, что увидят только сотрудники (внутренняя заметка), и те, что уйдут клиенту. Разделение работает на стороне сервера, а не «на доверии»: внутренняя заметка физически не может попасть в письмо клиенту или на его страницу в портале. Так исчезает самая неприятная ошибка сервиса — клиент случайно получает внутренний разбор.
Сроки и условия (SLA)
Сроки сервиса — это правило: сколько времени даётся на первый ответ и на решение, в зависимости от клиента и типа обращения. Устроено честно:
- Правило фиксируется при приёме. Какое правило подошло заявке в момент поступления, то и действует до конца — задним числом его не подменить.
- Считаются рабочие часы. Ночь, выходные и праздники не «съедают» ваш срок: задаётся календарь работы, и отсчёт идёт по нему.
- Паузы только по состоянию. Если ждём клиента, счётчик останавливается; автоматическое служебное сообщение паузой не считается.
- Нарушение срока — это факт. Он записан в истории заявки, а не спрятан в среднем показателе.
- Есть лестница предупреждений. Срок близок — сигнал; нарушен — сигнал руководству; с разумными паузами между ступенями, чтобы оповещения не превратились в шум.
Макросы и массовые действия
Частые ответы сохраняются как заготовки: нажал — текст подставился, осталось дополнить деталями. Для групп заявок есть массовые действия: назначить, сменить статус, применить заготовку. Устроено с защитой от ошибок: перед применением видно, что именно произойдёт и с какими заявками, а неудачные строки не отменяют всю работу — они попадают в отчёт, а остальные обрабатываются.
Совместная работа
Над сложной заявкой работают вместе: можно позвать коллегу упоминанием, подписать наблюдателей, передать заявку или разделить её на части, если внутри две разные проблемы. Всё это записано в истории, поэтому понятно, кто и что сделал.
База знаний
Ответы, которые повторяются, стоит записать один раз. Статьи базы знаний собираются в категории, у них есть состояние (черновик, на проверке, опубликована, в архиве), срок пересмотра и круг читателей. Продукт подсказывает сотруднику подходящую статью по теме заявки, помогает вставить её текст в ответ и показывает, помогает ли статья на самом деле — читают ли её и решаются ли после этого обращения. Так база знаний не превращается в свалку неработающих инструкций.
Портал клиента
У клиента есть свой вход в сервис — отдельные страницы со своим доступом. Там он видит свои заявки и переписку, может оставить новую заявку по форме, посмотреть каталог услуг, получить отчёты и обменяться документами. Доступ ограничен строго: в портале никогда не показывается ничего из внутренней работы и чужие данные — всё это ограничивается до того, как страница открывается.
Портал — это отдельный мир, а не урезанный офис: клиент не видит внутренние экраны и не может попасть в них. Это сделано раздельно и намеренно, чтобы не приходилось надеяться на «не нажмёт».
Опросы клиентов
После решения заявки можно спросить клиента об обслуживании — коротким опросом. Важно, что у оценки есть последствия: недовольный клиент не остаётся строчкой в отчёте, по нему видно, что именно пошло не так, и с ним можно связаться. Так собирается обратная связь, которую действительно используют.
Метрики сервиса
Показатели сервиса — время первого ответа, время решения, доля соблюдённых сроков, возврат обращений — считаются по опубликованным формулам. Рядом с каждой цифрой видно, из чего она сложилась: какой знаменатель, какие заявки в неё вошли. И есть принципиальное решение: продукт не строит рейтинги сотрудников. Метрики нужны, чтобы понимать, где узкое место в процессе, а не чтобы наказывать людей за сложные заявки.
Здоровье клиента
Отдельный экран показывает клиентов, у которых накопились тревожные признаки: много обращений, недовольные оценки, просрочки по оплате, затишье в общении. Каждый «красный» признак имеет хозяина — понятно, кто должен заняться. Это способ заметить уходящего клиента, пока он не ушёл, а не узнать об этом из отчёта о потерях.
Планирование смен
Сервис — это люди, и у них есть графики. Продукт показывает текущую нагрузку, прогноз по дням недели (когда обращений традиционно больше) и позволяет расставить смены. Это нужно, чтобы в понедельник утром не оказалось, что все обращения ждут одного человека.
Масштабные сбои, проблемы и изменения
Когда ломается не у одного клиента, а у всех сразу, удобно завести один инцидент и связать с ним все заявки. Тогда видно масштаб, и сроки по таким заявкам не считаются просроченными у каждого сотрудника по отдельности — честно, ведь сбой общий. Из повторяющихся сбоев вырастают «проблемы» и «известные ошибки»: записанное решение становится статьёй базы знаний. А планируемые работы ведутся как изменения с этапами согласования — чтобы правка не осталась неожиданностью.
Учёт оборудования клиентов
У клиента можно вести перечень оборудования и других объектов обслуживания: что стоит, когда куплено, где находится. Тогда в заявке видно, о чём именно речь, а сервисный инженер заранее знает, с чем имеет дело. Перечень загружается таблицей и ведётся вместе с историей обращений по каждой единице.
Договоры обслуживания
Если клиент на обслуживании по договору, продукт проверяет право на обслуживание прежде, чем считать сроки: по договору, по его сроку действия и по включённым услугам. Отдельно ведётся учёт часов: сколько по договору положено и сколько уже израсходовано, с возможностью докупить пакет. Если часы кончились, продукт скажет об этом, а не будет молча считать бесплатно.
Выездное обслуживание
Выезды оформляются отдельно: у выезда есть объект, время, состав работ и три отдельных отсчёта времени (например, дорога, работа, оформление) — так видно, куда уходит время. Плановые осмотры можно поставить на расписание, и они сами превращаются в задачи.
Партнёры
Партнёрам можно дать свой вход: они регистрируют клиентов и заявки, а продукт следит, чтобы два партнёра не привели одного и того же клиента, и передаёт заявки в общую работу. Так партнёрская сеть работает в тех же данных, что и собственный отдел, без отдельных таблиц.
Надстройки
Сервис — это восемь независимо включаемых надстроек: сам сервис, сроки, база знаний, портал клиента, опросы, учёт оборудования, договоры обслуживания и партнёрский портал. Можно начать с заявок и сроков, а остальное включить позже. Без любой из них остальные работают, а не отваливаются целиком.
Дальше → Надстройки и состав продукта