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

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

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

Схема 1. Вендорская поддержка с помощью партнеров

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

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

Схема 2. Сеть партнеров с привлечением вендора

Модель используется в случае необходимости присутствия «на местах» (например, для замены запчастей) или в случае постпроектного сопровождения (когда проекты внедрения также реализуют партнеры, и их же потом поддерживают). В рамках этой модели вендор «строит» партнерскую сеть, контракты поддержки конечные клиенты заключают с партнерами и, как следствие, обращения клиентов поступают к партнерам. При этом в рамках поддержки остаются вопросы на «третьей линии», которые требуют привлечения разработчика: исправление багов в системе, замена по гарантии, выпуск патчей и т. д.

Усложненная схема. Привлечение подрядчиков для решения части вопросов

Обе из вышеназванных моделей оказания технической и сервисной поддержки (в большей степени — вторая из них) на практике «усложнены» несколькими уровнями субподрядчиков, субпартнеров (нам известно об историях с 3 и даже 4 уровнями субпартнерства) и т. д. Это бывает, например, в случае федеральной компании-заказчика, требующей присутствия в нескольких регионах или в ситуациях, когда партнерская сеть изначально выстроена по модели эксклюзивности работы в регионе. 

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

Недостатки существующих моделей

У каждой из описанных моделей есть свои плюсы и минусы. Например, 1 схема позволяет вендору не только контролировать все вопросы клиентов и гарантировать более высокое качество поддержки, но и получать информацию «от первого лица», а значит развивать продукт и реагировать на клиентские запросы более оперативно и точечно. Еще одним несомненным преимуществом является возможность оценивать качество работы партнеров и оперативно вносить в схему взаимодействия изменения (например, менять партнёров, которые не справляются с задачами поддержки).

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

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

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

Помножив на автоматизацию

Проблемы, возникающие в обеих моделях, в реальности сильно усложняются, когда, как ни странно, подключается вопрос автоматизации техподдержки и этих самых коммуникаций. Дело в том, что подавляющее большинство как сервисных компаний, так и вендоров не используют никакие системы автоматизации, кроме e-mail или мессенджеров (по нашей статистике, таких ~ 90%). А те, что используют для регистрации, учета и обработки заявок какие-то решения по автоматизации, никак друг с другом не интегрированы. 

Получается парадоксальная ситуация: в любой из схем нужно автоматизировать сквозной процесс обработки клиентских заявок, но системы поддержки клиентов партнеров, субпартнеров и вендоров (если они существуют) на практике никак не связаны между собой (изредка посредством той же email пересылки). В редких случаях партнеры или подрядчики работают в системе заказчика или вендора. Это только добавляет проблем обеим сторонам, потому что приводит либо к избыточному лицензированию, либо «заставляет» работать подрядчика в отличающихся системах разных вендоров/ генподрядчиков (да, на рынке почти любая сервисная компания является одновременно партнером нескольких вендоров или более крупных сервисных компаний).

Итогом исторически сложившихся схем работы и единого решения описанных проблем в обеих схемах сотрудничества компании неизбежно сталкиваются с рядом издержек, например: 

Выход из ситуации 

Несомненно, выходом из сложившейся ситуации могла стать интеграция автоматизированных систем учета заявок всех задействованных сторон. Интеграция позволила бы решить все вышеобозначенные проблемы при работе в обеих схемам, включая усложненную. Но, как мы говорили, на практике лишь немногие компании используют какие-то готовые решения. Другая проблема — слабое присутствие на рынке  инструментов, позволяющих обеспечить «сквозную» интеграцию разных систем в части передачи заявок и совместной работы по ним (разработка таких решений сложная и дорогая).

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

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

В настоящий момент подобная модель используется в нескольких отраслях, в частности —  автоматизация HoReca и обслуживание контрольно-кассовой техники. Анализ реакции пользователей показывает, что в среднем интегрированные решения позволяют добиться сокращения времени на решение заявок до 40%, а количества негативных отзывов со стороны клиентов — примерно на 20%.