TikkeeШаг 1. Решите, что вы обещаете клиенту
Это первый шаг, а не последний, хотя почти все начинают с выбора программы. Пока не сформулировано обещание, непонятно, что вообще настраивать.
Ответьте на три вопроса:
- В какие часы вы принимаете обращения — 5×8, 24×7, что-то среднее?
- За какое время отвечаете и за какое решаете? Отдельно по критичным и обычным заявкам;
- Что считается критичной заявкой — у вас и у клиента это разные вещи, договоритесь на берегу.
Записанные ответы — это и есть ваш SLA. Обещайте меньше, чем можете: перевыполненный скромный SLA работает на репутацию лучше, чем сорванный амбициозный.
Шаг 2. Сведите каналы в одну точку
Классическая картина на старте: часть заявок в почте, часть в WhatsApp у менеджера, часть — звонком лично инженеру. Пока это так, никакой учёт невозможен: вы не управляете тем, чего не видите.
Правило простое: клиент пишет туда, куда ему удобно, но всё падает в одно место. Не заставляйте клиентов менять привычки — заставьте систему собирать их обращения. Почта, Telegram, звонок, веб-форма должны превращаться в заявку автоматически.
Отдельно про полевых инженеров: им неудобно печатать. Возможность надиктовать голосовое, из которого система сама сделает заявку, снимает главную причину «забыл записать».
Шаг 3. Договоритесь, кто за что отвечает
Даже в команде из трёх человек нужны роли, иначе заявка «висит на всех», то есть ни на ком.
Линии поддержки
Первая линия принимает и решает типовое по инструкции. Вторая — то, что требует квалификации. Разделение окупается сразу: дорогой инженер перестаёт тратить время на «перезагрузите роутер». В маленькой команде линии — это не разные люди, а разные режимы работы одного человека.
Правила эскалации
Заранее решите, при каких условиях заявка уходит выше: не решается за N часов, задет критичный сервис, клиент из ключевых. Без явного правила эскалация происходит по громкости клиента, а не по важности задачи.
Один ответственный на заявку
У любой заявки в любой момент есть ровно один владелец. Это самое дешёвое правило из всех — и самое часто нарушаемое.
Шаг 4. Выберите инструмент под процесс
Только теперь — программа. И выбирается она под то, что вы описали выше, а не наоборот.
Минимум для сервисной компании: приём из ваших каналов, SLA по договорам, карточка клиента с объектами и оборудованием, учёт трудозатрат, отчёты. Если чего-то из этого нет — процесс придётся подгонять под инструмент, и он развалится.
Не берите на старте тяжёлое ITSM-решение «на вырост». Оно требует внедренцев и месяцев настройки, а вам нужно принимать заявки на этой неделе. Tikkee здесь как раз про быстрый старт: регистрация, подключение почты или Telegram — и приём заявок в тот же день, с возможностью включить SLA, CRM и отчёты по мере роста.
Шаг 5. Заведите базу знаний сразу
Не «когда накопится опыт» — накопление опыта и есть база знаний. С первой недели действует правило: закрыли нетиповую заявку — описали решение.
Через три месяца у вас будет 30–40 статей, которые закрывают большую часть потока. Через три месяца без этого правила у вас будет ноль статей и те же вопросы к тем же людям.
Шаг 6. Считайте и улучшайте
Начните с трёх метрик, не больше: время реакции, время решения, доля нарушений SLA. Их достаточно, чтобы увидеть проблему; остальное добавите, когда эти три перестанут её объяснять.
Раз в месяц смотрите на самые частые типы обращений. Если один и тот же тип держится в топе — это не работа поддержки, это дефект, который надо чинить в корне или закрывать инструкцией.
Частые ошибки на старте
- Начать с выбора софта, а не с обещания клиенту — потом всё равно переделывать;
- Обещать 24×7 при команде из двух человек — сорванный SLA хуже отсутствия SLA;
- Оставить «удобный» канал в личном WhatsApp менеджера — эти заявки не попадут в учёт никогда;
- Внедрять тяжёлую систему на 15 заявок в неделю;
- Считать десять метрик с первого дня вместо трёх и не делать по ним ничего.