Поддержка продукта — это то, как клиенты формируют устойчивое впечатление о вашей компании. С Trupeer вы можете сэкономить часы на подготовке документации по поддержке: начните с бесплатного шаблона SOP по поддержке продукта, настройте его с помощью бренд-гайдов и используйте наш AI-создатель SOP, чтобы превратить каждую процедуру в понятный видеогайд.

Для чего используется шаблон SOP по поддержке продукта?

SOP по поддержке продукта — это письменная процедура для обработки повторяющегося типа обращений клиентов по продукту: что спрашивать, что проверять, как решать, когда эскалировать и что сообщать клиенту.

Шаблон дает вам повторно используемую основу. Триггер, предпосылки, шаги, решение, эскалация, формулировки для клиента.

Он тесно связан с SOP по обслуживанию клиентов и не является тем же документом — по одной причине, которая определяет всё на этой странице. В поддержке продукта есть продукт, и продукт может быть неправильным. Процедура обслуживания клиентов обрабатывает ситуацию. Процедура поддержки продукта часто обрабатывает неисправность, и то, что она делает с этой неисправностью, определяет, будет ли в ближайшие два года расти или падать объем обращений.

Для общей структуры наш шаблон SOP подходит, а наш шаблон IT SOP описывает внутренние технические операции. Эта страница объясняет, что меняется, когда то, что вы поддерживаете, — это продукт, который кто-то другой может исправить.

У каждой процедуры поддержки два результата, а не один

Обычно SOP поддержки оценивают по одному: решает ли он обращение быстро и последовательно. Это разумная метрика — и это половина работы.

Вторая половина — сигнал. Поддержка находится в единственной точке организации, где каждая неисправность проявляется, в объеме, с приложенными доказательствами. Никто другой не видит эту картину. Инженерия видит баги, о которых ей сообщили. Продукт видит дорожную карту. Поддержка видит, что на самом деле происходит с клиентами — четыреста раз в месяц.

Поэтому у каждой процедуры есть два возможных результата. Решение для этого клиента и отчет для тех, кто может остановить проблему.

Почти ни у одного SOP поддержки нет второго. Шаги заканчиваются на «подтвердите, что клиент доволен, и закройте тикет». Нет поля, где указать, что нужно поднимать, кому, с какими доказательствами, и на каком этапе повторяющееся решение перестает быть решением и становится дефектом.

Добавьте этот выход в каждую процедуру — и библиотека начинает работать иначе. Без него поддержка превращается в очень эффективный поглотитель неисправностей, а эффективность поглощения неисправностей неотличима от отсутствия проблем до тех пор, пока кто-то не посмотрит на объем обращений.

Как настроить этот шаблон в Trupeer

Шаг 1: Откройте раздел «Templates»

Перейдите в раздел Templates из главной навигации.

Шаг 2: Выберите и откройте шаблон

Нажмите на любой шаблон, с которым хотите работать, чтобы открыть его.

Шаг 3: Разверните просмотр шаблона

При необходимости разверните просмотр шаблона, чтобы увидеть полную раскладку и детали.

Шаг 4: Отредактируйте шаблон

Нажмите Edit, чтобы начать изменять выбранный шаблон.

В редакторе вы можете:

• Добавлять новые разделы

• Задавать или обновлять правила форматирования

• Добавить логотип и настроить его положение и связанные параметры

Шаг 5: Сохраните настроенный шаблон

После того как вы внесете все необходимые изменения, нажмите Save, чтобы сохранить обновленный шаблон как свой.

Шаг 6: Предпросмотр и точная настройка шаблона

Когда вы захотите увидеть, как выглядит ваш настроенный шаблон, откройте Preview.

На экране предпросмотра вы можете продолжить вносить правки напрямую при необходимости — так шаблон будет выглядеть ровно так, как вы хотите.

С шаблоном SOP по поддержке продукта вы можете:

• Экономить часы на написании: пропускайте пустую страницу — структура уже создана для процедур поддержки.

• Стандартизировать качество поддержки: каждый агент решает типовые проблемы одинаково.

• Оставаться в фирменном стиле: применяйте логотип, тон и цвета с помощью бренд-набора Trupeer.

• Сокращать время решения: четкие процедуры помогают агентам разбираться с проблемами быстрее.

• Быстрее обучать агентов: сочетайте SOP с видеогайдами, чтобы быстрее вводить в работу новых сотрудников.

• Достигать глобальных команд: переводите SOP по поддержке продукта на 65+ языков одним кликом.

Ваша библиотека обходных решений — это неучтенный бэклог багов

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

Пройдитесь по своим процедурам поддержки и найдите формулировки, которые указывают на обходное решение. Как временная мера. Это известная проблема. Посоветуйте клиенту. Пусть они сбросят и попробуют снова. Если не сработает — попробуйте.

Каждое из этих действий — это дефект продукта, с которым кто-то решил мириться. Не намеренно — в большинстве случаев. Кто-то написал хорошую процедуру, чтобы помочь коллегам справляться с проблемой, процедура работала, обращения обрабатывались эффективно, и неисправность перестала создавать давление с требованием ее исправить.

Посчитайте их — и вы получите бэклог багов, который больше нигде в организации не существует. Сопоставьте каждый случай с объемом обращений и временем обработки — и вы получите бэклог, ранжированный по стоимости. Это больше, чем большинство продуктовых команд имеют для своего реального бэклога.

Неприятное открытие в том, что написание очень хорошей SOP с обходным решением активно откладывает исправление. Чем лучше процедура, тем меньше шума создает неисправность, и тем дольше она «живет».

Как найти обходные решения, которые уже есть в ваших SOP

Работа на полдня — и не требует сотрудничества ни от кого.

Найдите в библиотеке процедур формулировки из списка выше. В большинстве библиотек это обнаруживает от пятнадцати до тридцати процентов процедур.

Для каждого совпадения зафиксируйте: какая процедура, какая базовая неисправность, сколько обращений она сгенерировала за последние двенадцать месяцев, среднее время обработки и поднимался ли этот случай когда-либо как дефект.

Последняя колонка удивляет людей. Большая часть задокументированных обходных решений никогда не сообщалась формально — потому что человек, который написал процедуру, решил проблему тем способом, который был доступен ему: написать процедуру.

Умножьте количество обращений на время обработки, чтобы получить часы, и умножьте часы на вашу «загруженную» стоимость — чтобы получить число. Отсортируйте по убыванию. Топ-5 обычно составляют большую часть общего объема, и именно они — ваши кейсы для реестра, описанного ниже.

Не подавайте это как провал команды поддержки. Они сделали то, что было в их силах, и сделали это хорошо.

Триггер повторяемости, который превращает исправление в дефект

Механизм, который предотвращает повторение, прописан в самой процедуре в виде порога.

Эти цифры нужно установить относительно ваших собственных объемов. Важно, чтобы порог существовал и чтобы его пересечение приводило к действию, которое никто не обязан быть достаточно смелым, чтобы инициировать.

Последняя строка меняет поведение. Принятие постоянного обходного решения — это законное решение, и его нужно принимать явно: человеком с полномочиями, и фиксировать. Нелегитимно то, что это решение принимается по умолчанию — потому что никто никогда не поднимал этот вопрос.

Бесплатный шаблон SOP по поддержке продукта: структура для копирования

Скопируйте отсюда. Поля, отмеченные звездочкой, — это добавления к стандартному SOP.

Заголовок. Номер процедуры и название, сформулированные как симптом клиента, а не как внутренняя причина. Владелец. Дата последней проверки. Затронутые продукты и версии. Оценочное время обработки. Ссылка на известную проблему, если она существует.

Симптом. Как клиент описывает это, его словами, включая типовые варианты формулировок. Именно по этому будут искать агенты.

Не используйте эту процедуру, если. Условия, при которых это неверная процедура, с указанием на правильную.

Диагностические вопросы. Что нужно установить до того, как делать что-либо, в порядке, который быстрее всего исключает большинство случаев.

Шаги решения. Пронумерованные, по одному действию на каждый шаг, с ожидаемым результатом. Если шаг — это обходное решение для известной неисправности, отметьте его как таковой, а не представляйте как предполагаемое поведение.

Формулировки для клиента. Что сказать, включая то, чего обещать нельзя. Этот раздел останавливает ситуацию, когда двенадцать агентов дают двенадцать разных описаний одной и той же неисправности, и наш шаблон ответа службы поддержки раскрывает слой формулировок более глубоко.

Эскалация. Кому, на каком этапе и с какой информацией, приложенной к обращению.

Маршрут по дефекту. Что нужно передать продукту или инженерии, в каком виде, и какие доказательства требуются. Включите порог повторяемости, который делает это обязательным, а не опциональным.

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

Скопируйте отсюда. Два поля, которые важнее всего, — это ссылка на известную проблему и маршрут по дефекту, и именно их не даст вам ни один общий шаблон SOP.

Аудиокомпания с тридцатью одним скрытым дефектом

Vantree Audio производит потребительскую беспроводную акустику и наушники. Примерно сто сорок агентов поддержки на двух площадках обрабатывают около четырнадцати тысяч обращений в месяц.

По общепринятым метрикам функция поддержки была в хорошем состоянии. Сто сорок задокументированных процедур, хорошо поддерживаемых, время решения укладывалось в целевые значения, удовлетворенность клиентов — 4,2 из 5.

Число, которое не сходилось, — это обращения на единицу проданного товара: оно росло три года подряд.

Кто-то искал в библиотеке процедур формулировки про обходные решения. Тридцать одно из ста сорока процедур содержало задокументированное обходное решение для известной неисправности продукта.

Если сопоставить их с объемом тикетов, эти тридцать одна процедура составляли тридцать восемь процентов всех обращений.

Самая крупная из них — это неисправность сопряжения Bluetooth в одной модели, где обходное решение представляло собой последовательность сброса из шести шагов. Две тысячи девятьсот обращений за двенадцать месяцев при среднем времени обработки одиннадцать минут — это примерно пятьсот тридцать часов работы одного агента на одну неисправность.

Эта процедура была написана на третьем месяце после запуска модели — старшим агентом, чтобы помочь коллегам. Спустя двадцать шесть месяцев она всё еще оставалась в библиотеке. Инженерии о ней никогда не сообщали, потому что процедура работала. Обращения обрабатывались эффективно и последовательно, поэтому неисправность нигде не создавала давления.

Из тридцати одного обходного решения девятнадцать вообще никогда не поднимались как дефект. Восемь поднимались один раз и больше не получали продолжения. Четыре были известны инженерии и намеренно откладывались.

По всем тридцати одному ежегодная стоимость составила примерно пять тысяч триста часов работы агентов — где-то около ста шести тысяч фунтов только на обработку, прежде чем учитывать возвраты или влияние на удовлетворенность.

После этого последовали три изменения. Каждая процедура получила маршрут по дефекту. Встроили триггер повторяемости: любая процедура, содержащая обходное решение и вызываемая более пятидесяти раз за квартал, автоматически запускает рассмотрение дефекта. И создали реестр обходных решений: его ежемесячно просматривали вместе с продуктом и инженерией, ранжируя по формуле «обращения, умноженные на время обработки».

Правило, привязанное к реестру, было самым важным: обходное решение может существовать два квартала, после чего ему нужна либо дата исправления, либо зафиксированное решение принять его навсегда.

Через двенадцать месяцев одиннадцать из тридцати одного были исправлены в продукте или прошивке. Обращения по этим одиннадцати снизились примерно на семьдесят четыре процента. Обращения на единицу проданного товара по всему ассортименту снизились на девятнадцать процентов. Реестр стоял на четырнадцати открытых обходных решениях, девять из которых имели даты исправления.

Неисправность Bluetooth была исправлена в релизе прошивки через четыре месяца после начала работы с реестром — за это время она пережила двадцать шесть месяцев качественной обработки.

Какие SOP по поддержке продукта писать в первую очередь

Не сложные. Пишите процедуры, где большой объем обращений, или где агенты сейчас импровизируют: именно в этих двух местах последовательность дает максимальную отдачу.

Отсортируйте причины обращений по объему и напишите топ-10. В большинстве операций поддержки топ-10 составляют более половины всех обращений, и обычно они не выглядят «громко»: настройка и первое использование, подключение, учетная запись и вход, вопросы по оплате, возвраты и гарантия, обновления прошивки или ПО, вопросы совместимости, а также две-три неисправности, характерные именно для ваших текущих продуктов.

Затем добавьте те, где ошибиться дорого, а не просто часто. Обращения, связанные с безопасностью, любые случаи, где есть отзыв или регуляторное обязательство, запросы по данным или приватности, а также любые обращения, где неверный ответ создает юридическое обязательство.

Для коротких справок, которые агентам нужны прямо в момент звонка, а не для полной процедуры, job aid обычно подходит лучше, чем расширение SOP.

Десять–пятнадцать процедур, покрывающих ваш список по объему, плюс случаи с высоким риском последствий — это рабочая библиотека. Попытка написать сто сорок процедур с нуля — это то, из-за чего такие проекты обычно буксуют.

Как написать SOP по поддержке: шаг за шагом

Начните с реальных обращений, а не с документации по продукту. Прочитайте последние двадцать тикетов по теме и возьмите формулировки клиента для симптома — потому что именно по ним будут искать агенты.

Пишите диагностические вопросы в порядке, который быстрее всего исключает большинство случаев. В большинстве процедур их задают в порядке, в котором устроен продукт, а не в порядке, который быстрее всего приводит к решению.

Пишите шаги, наблюдая, как кто-то решает реальный кейс, а не исходя из того, как это «должно» работать.

Отмечайте каждое обходное решение как обходное решение. Эта одна привычка — то, что делает аудит выше возможным позже.

Напишите формулировки для клиента, включая то, чего нельзя говорить, и согласуйте их с тем, кто отвечает за внешние коммуникации продукта.

Задайте маршрут по дефекту и порог повторяемости до публикации, а не как последующее действие.

Затем пусть кто-то, кто не обрабатывал этот тип обращений, решит реальный кейс по процедуре, пока вы наблюдаете и не говорите ничего.

Эскалация, критичность и когда прекращать диагностику

Вторая характеристика, которой обычно не хватает в процедурах поддержки, — это правило остановки.

Агенты продолжают диагностику, потому что остановка ощущается как отказ, и потому что эскалация в большинстве команд поддержки имеет социальную цену. Поэтому обращение, которое нужно было эскалировать через двенадцать минут, тянется сорок, и клиент сталкивается и с задержкой, и с тем, что в итоге его передают дальше.

Пропишите правило остановки в процедуре. После заданного количества диагностических шагов, или заданного времени, или при обнаружении конкретного факта процедура заканчивается и начинается эскалация. Сделайте это инструкцией, а не оценкой.

Сопоставьте это с определениями критичности, которые можно наблюдать, а не описывать. Не «высокий эффект», а что-то вроде: клиент не может использовать ключевую функцию, или сообщается о проблеме безопасности, или сегодня один и тот же симптом уже сообщили более чем один клиент.

И определите, что именно передается вместе с эскалацией. Эскалация без приложенной диагностической истории отправляется обратно — и это стоит клиенту еще одного цикла. Наш шаблон тикета и решения описывает поля, которые нужно зафиксировать, чтобы передача сработала.

SOP по поддержке продукта или SOP по обслуживанию клиентов?

Оба существуют, они пересекаются, и различие стоит сохранять, потому что они «ломаются» по-разному.

SOP по обслуживанию клиентов обрабатывает отношения и транзакцию: заказы, жалобы, возвраты, изменения в аккаунте, общие запросы. Переменная — ситуация клиента, и хорошая процедура дает последовательный и справедливый результат.

SOP по поддержке продукта обрабатывает техническую проблему с продуктом. Переменная — поведение продукта, и хорошая процедура дает решение и, когда виноват продукт, сигнал.

Большинству организаций поддержки нужны обе, и процедуры должны жить в одной библиотеке с понятным маркером типа каждой: агенты не должны «ощущать» различие и не должны заставлять себя разбираться в нем.

Если ваша команда не обрабатывает технические неисправности, вам нужна структура обслуживания клиентов. Если ваша команда регулярно документирует обходные решения — эта страница более релевантна, и аудит обходных решений стоит провести уже на этой неделе.

Могу ли я получить шаблон SOP по поддержке продукта в Word или Excel?

Word или Google Docs — для самой процедуры. Это текст с пронумерованными шагами и формулировками для клиента, и его читают, а не сортируют.

Excel — для двух вещей, которые важнее, чем отдельная процедура. Реестр процедур: список каждого SOP с владельцем, датой последней проверки, объемом обращений, средним временем обработки и тем, содержит ли он обходное решение. И реестр обходных решений: неисправность, обращения, часы, поднимался ли дефект, а также дата исправления или принятое решение.

Вторая таблица — это артефакт, ради которого существует вся эта страница. На сборку уходит полдня, и обычно это первый раз, когда кто-то в бизнесе видит стоимость незакрытых неисправностей в одном месте.

PDF — для всего, чем делятся вне команды поддержки, например, процедура, прикрепленная к партнерскому соглашению, или показанная во время аудита.

Как держать процедуры поддержки актуальными по мере выхода продукта

Процедуры поддержки продукта устаревают быстрее, чем любые другие: то, что они описывают, меняется в релизном графике чужого релиза. Обновление прошивки меняет меню, релиз ПО убирает настройку, и сорок процедур становятся слегка неверными за неделю, о которой в поддержке никто не был предупрежден.

Практическое следствие в том, что поддержание библиотеки конкурирует с обработкой обращений, и обработка обращений всегда побеждает.

Trupeer AI убирает большую часть этой стоимости. Агент один раз решает обращение с включенной записью, а результат — это письменная процедура со шагами и экранами, которые уже зафиксированы, готовая к проверке, а не к написанию. Обновление сорока процедур после релиза превращается в день, а не в проект, который никто не начинает.

Записывайте. Брендируйте. Переводите. Trupeer’ьте.

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

Часто задаваемые вопросы

Есть ли бесплатный шаблон SOP по поддержке продукта в Word?

Структура выше вставляется прямо в Word или Google Docs, включая поля со ссылкой на известную проблему и маршрутом по дефекту, которые обычно опускают общие шаблоны SOP. Нет ограниченной загрузки и нет формы. Первое поле, которое стоит добавить к тому, что вы уже используете, — это маркер в каждом шаге, что это обходное решение.

Есть ли бесплатный шаблон SOP по поддержке продукта в Excel?

Excel подходит для двух реестров, а не для самой процедуры. Реестр процедур с объемом и временем обработки, и реестр обходных решений с неисправностью, ее стоимостью и датой исправления. Построение второго — это единственный самый высокий возврат за полдня, доступный большинству функций поддержки.

Есть ли бесплатный шаблон SOP по поддержке продукта в PDF?

Экспортируйте процедуры в PDF для всего, чем делятся вне команды, и сохраняйте рабочие версии редактируемыми. Процедуры поддержки меняются с каждым релизом продукта, поэтому «замороженная» библиотека начинает работать неправильно быстрее, чем большинство.

Где найти общий шаблон SOP в Word или PDF?

Если вам нужна стандартная структура без полей поддержки продукта, наш шаблон SOP подходит, а шаблон IT SOP описывает внутренние технические операции, включая то, как решить, какие процедуры вообще стоит писать.

Сколько SOP по поддержке продукта нужно команде?

От десяти до пятнадцати, покрывающих ваши самые частые причины обращений, плюс случаи с высоким риском последствий — независимо от объема. После примерно сорока поддержание становится главным ограничением, и меньшая библиотека, которая действительно актуальна, выигрывает у большой — той, которой агенты уже научились не доверять.

Кто должен писать SOP по поддержке продукта?

Опытные агенты, отредактированные тем, кто владеет библиотекой, с согласованием со стороны продукта или инженерии по любому описанию известной неисправности. Именно эта последняя проверка превращает обходное решение в видимый дефект, а не в локальное исправление — это и есть главный аргумент на этой странице.

Как часто нужно пересматривать SOP поддержки?

По релизам продукта, а не по календарю. Каждый релиз прошивки или ПО должен запускать проверку процедур, которые затрагивают то, что изменилось. Добавьте скользящий пересмотр топ-20 по объему каждый квартал и повторно верифицируйте всё, что приводило к эскалации.

SOP поддержки или статья базы знаний: в чем разница?

SOP — внутренний документ: он говорит агенту, как обработать обращение, включая то, что нужно эскалировать, и что нельзя обещать. Статья ориентирована на клиента и объясняет, как клиенту решить проблему самостоятельно. Обычно они появляются из одного и того же расследования и их стоит писать вместе, потому что хорошая статья убирает обращение полностью.