SaaS по подписке
Платящие клиенты ожидают SLA. Чтобы не терять подписчиков, время ответа решает всё: поддержка по договору напрямую снижает отток.
Техническая поддержка (SLA)
Время пошло
Вам уже отвечают
В ту же секунду, когда ваш клиент открывает тикет, запускается отсчёт по SLA (соглашению об уровне сервиса). Команда Partnerfy обеспечивает закрытие каждого тикета в рамках SLA: ротация дежурств 24/7, автоматическое подтверждение, база знаний с поддержкой ИИ и чёткая цепочка эскалации. Среднее время первого ответа у нас держится на уровне 4 мин 12 с, а в рамках SLA решается 98,7% тикетов.
Фраза «мы посмотрим» стоит вам контракта с клиентом. Работа по дисциплине SLA — обязательства, измерения, отчётность — превращает поддержку из центра затрат в центр дохода.
Очередь тикетов
live
КРИТИЧЕСКИЙ
#4821 · 02:14
Ошибка 500 при оплате — оформление заказа не работает
ВЫСОКИЙ
#4820 · 18:32
Превышен лимит запросов к API — интеграционный партнёр
ВЫСОКИЙ
#4819 · 42:07
Сбой входа через SSO — корпоративный аккаунт
СРЕДНИЙ
#4818 · 1h 12m
Экспорт отчёта выгружает пустой CSV
СРЕДНИЙ
#4817 · 2h 36m
Письма-уведомления попадают в спам
НИЗКИЙ
#4816 · 4h 02m
Не загружается аватар на странице профиля
#4821
Ошибка 500 при оплате
Получен09:31:00
Подтверждён09:31:47
В работе09:33:12
Решён—
Автоматически подтверждён за 47 с
Табло SLA · Этот месяц
Ср. первый ответ
4m 12s
Решено в рамках SLA
98.7%
CSAT
4.8 / 5
последние 12 недель — соблюдение SLA, %
Ротация дежурств 24/7
активная смена: Берлин
Азия · 00:00–08:00
Стамбул · 08:00–16:00
Берлин/ЕС · 16:00–24:00
Проблема
Большинство схем поддержки разваливаются при первом серьёзном кризисе
Первая причина: SLA не определено. «Посмотрим при первой возможности» — это не обязательство, а доброе намерение, которое невозможно измерить. Клиент не знает, когда получит ответ, начинает тревожиться и засыпает команду письмами, а силы сотрудников уходят не на решение проблемы, а на объяснения, когда она будет решена. Если для критического, высокого, среднего и низкого приоритетов нет письменно закреплённых целей по ответу и решению, все тикеты одинаково срочные — а значит, ни один из них не срочный.
Вторая причина: тикеты теряются. Когда обращения по-прежнему приходят на общий адрес «info@», на одно и то же письмо отвечают три разных человека или не отвечает никто; цепочки в копии ветвятся, вложения теряются, и уже непонятно, какая переписка относится к какому клиенту. Каналы — WhatsApp, телефон, форма, чат — ничего не знают друг о друге. Клиенту каждый раз приходится заново пересказывать свою историю. Это не только выглядит непрофессионально, но и становится главным препятствием на пути к измеримой работе поддержки.
Третья причина: нет эскалации. Когда специалист L1 не может решить проблему, непонятно, кому её передать. Фраза «спрошу у CTO» превращается в случайный канал, который будит топ-менеджеров в 23:00. Опытные (senior) инженеры, вынужденные в пятый раз объяснять одну и ту же проблему, начинают нервничать; падают скорость решения, качество и моральный дух команды. Пока нет письменно закреплённого пути эскалации L1 → L2 → L3 → архитекторы → руководство, кризисы каждый раз решаются паникой, а не системой.
Четвёртая причина: нет ротации дежурств. Если всё знание держится на одном человеке, на время его отпуска система остаётся без защиты; если посреди ночи, во время критического инцидента, его телефон выключен, всем остальным остаётся только ждать утра. Без таких инструментов, как PagerDuty или Opsgenie, без недельных графиков смен и без прозрачности в вопросе, кто дежурит прямо сейчас, дежурство превращается в добровольный героизм — неустойчивый, изматывающий команду и приводящий к ошибочным решениям.
Пятая причина: нет базы знаний, а повторяющиеся вопросы никогда не документируются. Один и тот же вопрос «как сбросить пароль?» может приходить 40 раз в месяц, и каждый раз инженер поддержки тратит на него 8 минут. Решение — написать статью в базу знаний при первом же обращении и настроить систему так, чтобы она сразу при открытии тикета предлагала клиенту: «Вы читали эту статью?». Каждая ненаписанная статья — это медленный сервис для клиента и налог на время, который команда платит каждый месяц. В пакете поддержки Partnerfy по SLA создание базы знаний — не опция, а основа всей работы.
Система
За каждым тикетом стоят три отдельных механизма
Как только клиент начинает вводить заголовок, срабатывают ИИ-подсказки из базы знаний; при открытии тикета автоматически запускается цепочка эскалации; в конце месяца вы видите долю решений с первого обращения на наглядной круговой диаграмме.
Автоподсказки из базы знаний
оплата не проходит checkout
Ошибка 500 при оформлении заказа — частые причины
0.94
Отладка таймаута платёжного провайдера
0.86
Сбой в сценарии 3-D Secure
0.71
Пока клиент вводит заголовок, появляются три наиболее подходящие статьи с оценкой сходства: проблема, решённая до открытия тикета, — это самая быстрая поддержка.
Цепочка эскалации
Если L1 не отвечает в течение 15 мин, тикет автоматически уходит на L2; если за 1 час решения нет — инженеру L3; при критическом инциденте уведомляется CTO. Всё закреплено письменно, всё поддаётся аудиту.
Решение с первого обращения
73%
FCR
73% тикетов решаются с первого ответа — благодаря подсказкам из базы знаний, регламентам (runbook) и правильному распределению на L1. До эскалации доходят только настоящие инженерные случаи.
Кому подходит
8 сценариев, в которых дисциплина SLA не обсуждается
Электронная коммерция
Заказы, доставка, возвраты — большие ежедневные объёмы. В пики приходят десятки тикетов в минуту; точная сортировка и быстрый ответ напрямую превращаются в выручку.
Крупный B2B-бизнес
В корпоративных договорах SLA оформляется приложением. Нарушение — это бесплатный период и удар по репутации; поддержка, которая измеряется и отражается в отчётах, обязательна.
Агентства (20+ клиентов)
Сайты, кампании и панели множества клиентов. Одна служба поддержки обеспечивает SLA для всего портфеля.
Финтех
Регуляторные запросы, платёжные споры, тикеты по KYC. SLA, журнал аудита и эскалация — обязательное условие готовности к проверкам.
Здравоохранение / клиники
Сбои в записи на приём, пациентском портале и электронных рецептах — приоритет критический. Медленный ответ — это не операционный ущерб, а прямой риск для пациента.
Производство / промышленность
ERP, MES, IoT на производственных площадках: простой останавливает производственную линию. Минута обходится в тысячи турецких лир; поддержка 24/7 — не роскошь, а необходимость.
Средний бизнес (50–200 сотрудников)
Когда внутренние инструменты выходят из строя, останавливается вся компания. ИТ-служба поддержки и поддержка приложений в рамках единого SLA.
Услуги
От настройки helpdesk до процессов ITIL: 10 уровней услуг
Внедрение helpdesk-платформы
Zendesk, Freshdesk, Intercom: выбираем подходящую для вашего бренда и команды, внедряем её и оформляем клиентский портал в стиле бренда.
Разработка политики SLA
Отдельные цели по ответу и решению для критического, высокого, среднего и низкого приоритетов, определение рабочих часов, календарь праздников, пороговые значения для отчётности.
Ротация дежурств
Недельные смены через PagerDuty / Opsgenie, основной и резервный дежурные, политики эскалации и оповещения по телефону, SMS и в Slack.
Многоканальный приём тикетов
Электронная почта, онлайн-чат, WhatsApp Business, клиентский портал, Slack — всё объединяется в единую систему тикетов, а история клиента видна из любого канала.
База знаний и ИИ-подсказки
Пишем и классифицируем статьи базы знаний, настраиваем поисковый индекс; при открытии тикета и в онлайн-чате ИИ предлагает подходящие статьи.
Регламенты эскалации (runbook)
Пошаговые инструкции для более чем 30 самых частых сценариев. Команда L1 может закрыть проблему самостоятельно; масштаб растёт, качество остаётся стабильным.
Опросы CSAT / NPS / CES
Автоматический опрос при закрытии каждого тикета; результаты на дашборде; тикеты с низкой оценкой автоматически уходят на разбор.
Обучение команды
Для вашей внутренней службы поддержки: платформа, SLA, эскалация, написание статей базы знаний, общение с клиентами — письменные материалы, занятия в классе и обучение на рабочем месте.
Ежемесячный бизнес-обзор
30-минутная встреча: соблюдение SLA, самые проблемные области, использование базы знаний, нагрузка на команду, рекомендуемые улучшения — письменный отчёт и живая сессия.
Управление изменениями и проблемами по ITIL
Управление инцидентами, проблемами (первопричины), изменениями, процессы разбора инцидентов (post-mortem) — реально работающие, а не только на бумаге.
Процесс
От текущей поддержки к дисциплине SLA: 6 шагов
-
01
Аудит текущей поддержки
2 недели — перечень каналов, объём тикетов, среднее время ответа, самые частые темы, структура команды, текущий набор инструментов. Выводы ранжируются по приоритету.
-
02
SLA по приоритетам
1 неделя — письменная матрица SLA: критический / высокий / средний / низкий × ответ / решение; рабочие часы или 24/7; правила эскалации. Согласование с юристами.
-
03
Выбор и внедрение платформы
2–3 недели — выбор между Zendesk / Freshdesk / Intercom; триггеры, автоматизации, правила SLA, брендирование клиентского портала, интеграция электронной почты, чата и WhatsApp.
-
04
Первичное наполнение базы знаний
2 недели — на основе 50 самых частых вопросов за последние 6 месяцев создаются статьи базы знаний; они классифицируются, индексируются для поиска, подключаются ИИ-подсказки.
-
05
Обучение и запуск в эксплуатацию
1 неделя — письменные материалы и занятия в классе для службы поддержки, в первую неделю параллельная работа (старая и новая системы), запуск в эксплуатацию после пилотного периода.
-
06
Ежемесячный обзор и улучшения
Постоянно — соблюдение SLA, FCR, CSAT, чаще всего повторяющиеся темы, обновления базы знаний; письменный отчёт и 30-минутный бизнес-обзор.
Наши инструменты
Корпоративные стандарты и интеграция с панелью ID.Partnerfy
Zendesk
Freshdesk
Intercom
HubSpot Service Hub
Salesforce Service Cloud
Help Scout
ServiceNow
Jira Service Management
Atlassian Confluence
Notion KB
OpsGenie
PagerDuty
Statuspage
Истории клиентов
Когда дисциплину SLA измеряют, цифры меняются
SaaS
4 ч → 7 мин
Вертикальный SaaS — 1200 клиентов
Среднее время первого ответа сократилось с 4 ч 12 мин до 7 мин; ежемесячный отток — с 3,8% до 2,1%; число отчётов о нарушении SLA снизилось на 94%.
Электронная коммерция
CSAT 3,8 → 4,7
Многокатегорийный магазин
CSAT вырос с 3,8 / 5 до 4,7 / 5; минуты поддержки на заказ сократились с 9,4 до 3,1; доля возвратов снизилась на 2,2%.
B2B
+14% удержание
Поставщик корпоративного ПО
Чистое удержание за 12 месяцев выросло на 14%; благодаря дисциплине SLA потери при продлении корпоративных договоров почти нулевые.
Финтех
11 ч → 47 мин
Платёжная платформа
Максимальная оценка по пункту «операционная устойчивость» на проверке регулятора; среднее время решения тикета сократилось с 11 ч до 47 мин.
Здравоохранение
−62% жалоб
Портал сети клиник
В пиковые периоды тикеты системы записи на приём закрываются в течение 4 часов; жалобы пациентов сократились на 62%.
Производство
−320 ч/год
Поддержка ERP
Благодаря дежурствам 24/7 среднее время реакции инженера на простои завода сократилось с 38 до 6 мин; потери производственной линии снизились на 320 часов в год.
Часто задаваемые вопросы
8 самых частых вопросов о внедрении поддержки по SLA
Все три платформы хороши; выбор начинается с профиля ваших клиентов. Крупный бизнес, несколько языков и сложные рабочие процессы — Zendesk: самая глубокая настройка и лучшая отчётность. Малый и средний бизнес, где важна скорость, — Freshdesk: более быстрое внедрение и более доступная цена. SaaS, поддержка через чат и сообщения внутри продукта — Intercom: на первом плане сценарии и взаимодействие с клиентами. Решение принимается не только по списку функций, но и с учётом размера команды, объёма тикетов, текущей CRM и долгосрочной дорожной карты; в первую неделю мы вместе проводим воркшоп по выбору, и вы начинаете, чётко видя следующие шаги.
То, что клиенты пользуются системой круглосуточно, ещё не значит, что поддержка должна работать 24/7; необходимость ответа определяется тем, во что простой обходится клиенту. Оформление заказа в интернет-магазине, упавшее в пиковую ночь, требует поддержки 24/7; внутреннему B2B-продукту обычно достаточно рабочих часов и дежурств. Наша рекомендация: ответ 24/7 для критического приоритета и рабочие часы для остальных. Такая гибридная модель удерживает расходы на разумном уровне и сводит риск к минимуму. Мы вместе проектируем матрицу SLA и находим правильный баланс; «24/7 для всего» для большинства компаний — избыточная инвестиция.
По трём параметрам: допустимые потери клиента (сколько часов он выдержит при критическом простое), предложения конкурентов (сложившиеся на рынке стандартные пороги) и ваши операционные возможности (цель, которую вы действительно сможете выполнять). Самая большая ловушка — «продать амбициозное SLA и не выполнить его»: нарушение означает бесплатный период. Наши общие ориентиры: критический — ответ 15 мин / решение 4 ч, высокий — 1 ч / 8 ч, средний — 4 ч / 1 рабочий день, низкий — 1 рабочий день / 3 рабочих дня. Мы калибруем их под вашу работу, договоры с клиентами и реальные измерения.
Да, можно, хотя не переносить всё — тоже вполне разумный вариант. Переносятся тикеты активных клиентов за последние 12 месяцев (обычно 5–30 тыс. тикетов); более старые данные архивируются и индексируются для поиска. Сохраняются данные клиентов, вложения, теги, категории, заметки о решении и оценки CSAT; идентификаторы агентов сопоставляются с пользователями новой системы. Миграция занимает 1–2 недели; в неделю параллельной работы действуют и старая, и новая системы, поэтому ни один диалог не теряется. В отчёте о миграции вы чётко видите, сколько записей перенесено, сколько ошибок исправлено и сколько дублей клиентов устранено.
Мы начинаем с архива тикетов за последние 6 месяцев: тематический анализ выявляет 50 самых частых проблем, и для каждой пишется пошаговое руководство (обычно 800–1500 слов, со скриншотами). Следующий слой — документация продукта: установка, первые шаги, продвинутые сценарии. Третий слой — регламенты (runbook): внутренняя документация вида «при такой ошибке выполните такие шаги». Вся база знаний попадает в систему индексации, подключается система ИИ-подсказок, и когда клиент пишет в чат, ему предлагаются 3 подходящие статьи. На ежемесячном обзоре измеряется, сколько просмотров получила каждая статья и какие из них сократили число тикетов.
Мы рекомендуем сочетать оба варианта. ИИ-чат-бот — первая линия защиты: он формирует ответы на основе базы знаний, понимает вопрос клиента и часто решает его без участия человека. Если решить не удаётся, он автоматически передаёт диалог живому оператору, и вся история переписки оказывается перед ним. Для обучения ИИ нужны более 200 примеров вопросов и ответов, материалы базы знаний и гайд по голосу бренда; первые три месяца работа ИИ еженедельно анализируется и улучшается. ИИ снижает нагрузку от обращений клиентов на 30–50% в большинстве компаний, но утверждение «ИИ решает всё» нереалистично: живая поддержка остаётся, а ИИ многократно повышает продуктивность этой команды.
Есть две основные модели. Первая: фиксированная ежемесячная плата с включённым числом тикетов и доплатой сверх него (например, 5000 тикетов включено, далее оплата за тикет). Это более предсказуемо, и такую модель выбирает большинство наших клиентов. Вторая: оплата только за тикет (например, в среднем 12–25 евро за тикет в зависимости от сложности). Какая модель выгоднее, зависит от объёма и распределения ваших тикетов; по данным первых трёх месяцев мы переходим на оптимальную модель. Критические тикеты тарифицируются с повышающим коэффициентом уровня; стоимость одного типового вопроса снижается за счёт того, что его берёт на себя ИИ (AI deflection).
Переход проходит в три этапа, и ни один тикет не теряется: мы это гарантируем. Первый этап — параллельная работа (dual-running): старый почтовый ящик и новый helpdesk работают вместе 7–10 дней, каждое входящее письмо видно в обеих системах, ни один канал не закрывается. Второй этап — мягкий переход: новые клиенты сразу попадают в новую систему; когда существующие клиенты пишут на старый адрес, письмо автоматически пересылается, а они получают уведомление. Третий этап — полное закрытие: старый адрес через автоответчик отправляет ссылку на новый портал и остаётся активным не менее 6 месяцев. Все тикеты за последние 12 месяцев становятся базой знаний с поиском; не теряется ни один диалог.
SLA начинается с договора, а не с обещания
За 30-минутную встречу мы вместе оценим вашу текущую поддержку и поделимся 3 приоритетными шагами по SLA, которые дадут результат в первые 60 дней.