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

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

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

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

Содержание

• Определение и границы процесса поддержки клиентов
• Модели процессов поддержки

  • Многоуровневая модель обработки обращений

    • Вариант 1. Одноуровневая обработка обращений
    • Вариант 2. Двухуровневая обработка обращений
    • Вариант 3. Трехуровневая обработка обращений
  • Управление предоставлением ИТ-сервисов (ITSM)

    • Соглашение об уровне сервиса (SLA)
    • Основные понятия ITSM в процессе обработки обращения
• Мониторинг эффективности процессов поддержки
• Заключение

Определение и границы процесса поддержки клиентов

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

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

• основные и вспомогательные бизнес-процессы
• основные средства для обеспечения сервисной деятельности
• специализированные информационные системы и оборудование (Service Desk, ПО Contact-центра и др.)
• персонал
• CRM-система, увязывающая информацию о предоставлении сервиса в общее хранилище данных по взаимоотношениям с потребителями, а также с другими ИС предприятия (ERP и др.)
• бизнес-процессы управления сервисной деятельностью, методики ее планирования и оценки эффективности
• соответствующий раздел стратегии компании, описывающий политику в области сервиса

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

Рассматриваемые ниже модели исходят из данного определения, не включающего в себя процессы продаж (в т.ч. продаж дополнительных продуктов и услуг – Up-Cross-Selling), маркетинга, предпродажной подготовки (Presale). В рамках сервисной поддержки взаимодействие происходит с уже существующим клиентом и исключительно по вопросам, связанным с использованием уже приобретенных им продуктов и услуг. При этом сервисная поддержка может оказываться как на безвозмездной (поддержка абонентов телекоммуникационных компаний), так и на возмездной основе (сервисное обслуживание автомобилей).

Кроме того, следует взглянуть на сервисную поддержку не только как на важную часть самой организации, но и как на важную составляющую ценностного предложения ее продуктов и услуг.

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

Параметры сервисной поддержки могут выступать в данном случае в качестве компонентов на всех трех уровнях ценностного предложения, придавая ему дополнительные конкурентные преимущества, например:

• сервисная поддержка сама по себе может являться продуктом – услуги аутсорсингового контакт-центра по обслуживанию клиентов внешних компаний
• сервисная поддержка может являться способом предложения основного продукта – покупатели некоторых программных продуктов получают права на их использование бесплатно, но заключают договора на консультации и решение проблем в процессе их использования с компанией-разработчиком
• сервисная поддержка является дополнением к основному предложению (наиболее распространенный случай) – бесплатное ТО автомобиля, вэб-портал самообслуживания владельцев банковских карт

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

Модели процессов поддержки

Многоуровневая модель обработки обращений

Единицей взаимодействия клиента со службой поддержки компании является его обращение с какой-то проблемой. Обращение может поступать в службу поддержки по различным каналам: телефонный звонок, e-mail, заполненная форма на сайте, ICQ и др. После поступления обращения в службу поддержки ее задача разобраться с ним (решить проблему клиента) в минимально возможные сроки и с наименьшими издержками при необходимом уровне качества. При этом обработка обращений в зависимости от специфики бизнеса компании может быть организована по-разному.

Вариант 1. Одноуровневая обработка обращений.

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

Плюсы такого подхода:

• Минимальное время решения проблем.
• Удобство общения для клиента.

Минусы:

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

Вариант 2. Двухуровневая обработка обращений.

Данная модель основана на том, что во многих сферах бизнеса большая часть обращений являются типовыми и не требуют высокой квалификации специалиста службы поддержки. Часто клиента интересуют элементарные вещи: ближайший банкомат или параметры настройки ADSL-модема. В этом случае обращения сначала попадает специалисту более низкой квалификации (1), который пытается самостоятельно решить проблему клиента при помощи созданных для этих целей информационных материалов и баз знаний. И только в случае, если решить проблему ему не удается он регистрирует ее и передает специалисту более высокой квалификации (2).

Процесс передачи обращения-телефонного звонка может происходить в режиме ON-LINE (переключения вызова) или в режиме OFF-LINE путем регистрации проблемы в системе Trouble-ticketing и маршрутизации ее на специалиста второй линии.

Плюсы:

• Обработка типовых задач специалистами менее высокой квалификации – экономия на заработной плате.
• Возможность иметь специализированных (по решению проблем конкретных типов) специалистов 2-го уровня. В этом случае оператор 1-й линии определяет тип проблемы и отправляет ее соответствующему сотруднику 2-й линии поддержки.

Минусы:

• Клиенту приходится общаться с разными сотрудниками поддержки, ждать соединения, объяснять проблему несколько раз.

Вариант 3. Трехуровневая обработка обращений.

Часто причины проблем клиентов могут быть как простыми, так и очень сложными. Примером могут быть проблемы абонента ADSL при попытке соединения с Интернетом, которые могут быть связаны как с неправильной настройкой модема, так и с характеристиками линии связи. Сложные проблемы часто не могут быть устранены ни специалистом 1-й линии, ни специалистом 2-й линии, т.к. требуют глубоких профильных знаний, доступа к соответствующему оборудованию и др. В этом случае обработка обращений ведется на трех уровнях.

1-й уровень, как и в двухуровневой модели – это специалисты средней квалификации, которые оказывают консультации и решают несложные проблемы (1). Если проблема не может быть решена на 1-м уровне, она передается на 2-й уровень (2). Специалист 2-го уровня – это диспетчер, универсальный специалист, который знаком со всем спектром возникающих проблем. Его задача ознакомиться с проблемой и спланировать ее решение с привлечением специалистов профильных служб – 3-й уровень. Он задает маршрут прохождения заявки на решение проблемы (в специализированной системе) между профильными подразделениями (3) и отслеживает ход ее выполнения. После чего, когда проблема устранена он либо закрывает ее, либо сообщает об этом специалисту 1-го уровня (4), который связывается с клиентом и просит убедиться, что проблемы действительно больше нет (5), после чего закрывает ее.

Плюсы:

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

Минусы:

• Обработка обращений может занимать несколько часов или дней.

Ну и наконец, стоит напомнить о том, что обработка обращений может вестись без участия оператора.

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

Управление предоставлением ИТ-сервисов (ITSM)

В настоящее время широкое распространение и популярность получили различного рода «библиотеки лучших практик», в которых в обобщенном и формализованном виде содержатся наработки компаний в определенных «предметных областях». Например, PMBoK в области управления проектами, eTOM – типовые бизнес-процессы оператора связи, ITIL – устройство ИТ-службы предприятия и др.

В этом разделе мы рассмотрим отдельные идеи методологии по управлению ИТ-услугами (IT Service Management), являющейся центральной частью библиотеки ITIL. В ITSM описывается взаимодействие между ИТ-службой и остальными подразделениями какой-либо компании. В качестве основного элемента этого взаимодействия рассматривается ИТ-сервис – услуга, которая оказывается ИТ-службой и используется бизнес-подразделениями. Примеры ИТ-сервисов: поддержка работоспособности компьютеров, администрирование и поддержка учетной системы и т.п. При этом ИТ-служба и бизнес-подразделение рассматриваются как достаточно обособленные субъекты, которые в общем случае могут находиться и в разных компаниях (аутсорсинг ИТ-услуг). Более того, в методологии ITSM многие базовые идеи не являются специфическими для ИТ и применимы не только для ИТ-услуг, но и для описания взаимодействия между поставщиком и потребителем услуг в иных сферах. В частности, если в качестве поставщика сервиса «Поддержка клиентов» рассматривать службу поддержки банка, а в качестве его потребителя клиента этого банка, то мы получаем возможность воспользоваться отдельными инструментами ITSM для описания процессов универсальной поддержки клиентов этого банка или какой-либо другой компании.

Рассмотрим две такие «универсальные идеи» ITSM:

• Описание характеристик предоставляемой услуги в соглашении об уровне сервиса (Service Level Agreement) и процедура обеспечение соответствия услуги заявленным параметрам SLA.
• Модель обработки обращения клиента в службу поддержки и соответствующая терминология.

Соглашение об уровне сервиса (SLA)

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

В самой компании при предоставлении услуги осуществляется определенный бизнес-процесс или группа процессов. Операции этих бизнес-процессов имеют определенные характеристики, влияющие на соблюдение значений параметров SLA. Задача менеджера, проектирующего услугу, в данном случае состоит в том, чтобы оценить и зафиксировать характеристики операций внутри компании в Operational Level Agreement (OLA), на их основе определить реалистичные значения показателей уровня сервиса для клиента, зафиксировать их в SLA и впоследствии отслеживать их соблюдение при каждом обращении клиента за данной услугой.

В случае если в рамках бизнес-процесса происходит взаимодействие с внешними компаниями-поставщиками, то в качестве OLA для таких операций при расчете клиентских SLA выступает SLA поставщика.

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

Основные понятия ITSM в процессе обработки обращения

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

• Заявка на обслуживание – зарегистрированное обращение клиента в службу поддержки
• Инцидент – факт несоответствия продукта или услуги компании заявленным характеристикам
• Проблема – причина несоответствия продукта или услуги компании заявленным характеристикам, обычно связана с одним или несколькими инцидентами
• Событие – факт несоответствия параметров функционирования элементов инфраструктуры компании регламентным значениям (обычно автоматически генерируются системой мониторинга в случае ее наличия)
• Изменение – набор действий, направленных на изменение в инфраструктуре или бизнес-процессах компании
• Service Desk – служба поддержки, единая точка входа для обращений клиентов компании

На следующей картинке изображен пример обработки обращения в службу поддержки с использованием этой терминологии.

В этом процессе все начинается с того, что клиент обращается в службу поддержки с каким-либо вопросом. Факт обращения регистрируется в виде заявки на обслуживание. Если это вопрос информационного плана ему оказываются соответствующие консультации и заявка тут же закрывается. Если в обращении содержится аргументированная претензия к качеству продукта или услуги, то фиксируется инцидент, который ассоциируется с данной заявкой. После этого специалисты компании занимаются выяснением причин и устранением инцидента. Инцидент может быть случайным, а может быть связан с систематическими сбоями в работе компании. В последнем случае, если налицо множество однотипных инцидентов регистрируется проблема. В любой момент времени клиент может повторно обратиться в службу поддержки, в этом случае ему сообщается текущий статус его заявки на обслуживание, обнаруженные инциденты и проблемы и ситуация с их решением. До специалистов, занимающихся устранением инцидентов и проблем, доводится информация о событиях, связанных с неправильным функционированием инфраструктуры компании, они учитывают эту информацию при поиске причин их возникновения. После устранения инцидента информация об этом передается клиенту и заявка закрывается.

Все перечисленные выше сущности и взаимосвязи между ними создаются, хранятся и обрабатываются в специализированной информационной системе — Service Desk (иногда ее также называют Order Management или Trouble Ticketing). При этом функции системы Service Desk не ограничиваются поддержкой workflow по работе с обращениями за поддержкой. Также эти системы занимаются формированием базы знаний службы поддержки (на основании информации, собранной в процессе поиска решений проблем), хранением информации об инфраструктуре предоставления услуг, управлением ею и др.

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

Мониторинг эффективности процессов поддержки

Приведенные выше модели помогают описать существующие или спроектировать перспективные бизнес-процессы по обработке обращений клиентов в службу поддержки, т.е. основу сервисной деятельности компании. Помимо разработки бизнес-процессов в рамках организации деятельности службы поддержки могут внедряться специализированные информационные системы (CRM, Service Desk, вэб-портал самообслуживания и др.), закупаться и устанавливаться необходимое оборудование (контакт-центр, сервера, СКС и др.). Т.е. тратятся деньги компании и часто немалые деньги.

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

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

Это, несомненно, важные и нужные показатели, однако, называть их показателями эффективности вряд ли правильно. Например, каково «эффективное» среднее время разговора? Может быть, чем меньше — тем лучше – экономия на зарплате операторов!? Тогда как быть с ситуацией, когда в результате длительного 15-минутного разговора клиент приобрел ряд дополнительных продуктов или услуг, а в результате короткого 30-секундного разговора только задал несложный вопрос? Или каков «эффективный» уровень загруженности операторов? Может быть, 100% — ведь надо максимально «эффективно» использовать персонал!? Тогда как быть, если действительно «эффективные» люди не идут работать в условиях такой «эффективности»? Может быть, «эффективный» процент потерянных вызовов – стремящийся к нулю? Тогда как быть со случаями, когда уровень доступности телефонной службы поддержки целенаправленно снижается, чтобы «приучить» клиентов пользоваться инструментами самообслуживания (вэб-портал, IVR) с целью снижения издержек?

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

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

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

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

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

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

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

Также следует отметить, что цели могут иметь иерархическую структуру. Например, цель «увеличение прибыли» содержит в себе две подцели: «увеличение доходов» и «снижение издержек».

В свете написанного выше предлагаю следующее определение: эффективность (чего-либо для компании) – степень соответствия чего-либо стратегическим целям компании, которые представляют из себя взаимоувязанные цели основных заинтересованных в деятельности компании сторон.

Исходя из такого определения, чтобы сделать что-то эффективно мы должны:

1. Сформулировать задачи этой деятельности в соответствии со стоящими целями.
2. Определить критерии соответствия того, что делается стоящим целям – ключевые показатели эффективности (КПЭ).

Например, задачами сервисной поддержки в данном случае могут являться:

• Для достижения цели «Снижение издержек»
  • Внедрение систем самообслуживания клиентов
  • Повышение производительности труда операторов за счет использования продвинутых систем распределения вызовов
• Для достижения цели «Повышение удовлетворенности сотрудников работой»
  • Внедрение продвинутой системы учета обработки обращений для оплаты по результатам
  • Оптимизация загрузки сотрудников

А показателями эффективности сервисной поддержки могут являться:

• Для достижения цели «Снижение издержек»
  • Средняя себестоимость обработки обращения
  • Доля обработки обращений в режиме самообслуживания
• Для достижения цели «Повышение удовлетворенности сотрудников работой»
  • Текучка кадров за месяц
  • Средняя субъективная оценка удовлетворенности сотрудника работой (информация может собираться путем анкетирования)

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

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

КПЭ должно быть немного. Они должны отражать ситуацию в очень обобщенном виде, пригодном для представления топ менеджменту компании – в очень сжатом виде позволять понять «что происходит» — в этом их преимущество. Недостаток их в том, что они не позволяют понять «почему это происходит». Для этого предназначаются детальные «технические» метрики, которые отражают те или иные аспекты происходящих процессов. Состав технических метрик, детализирующих КПЭ, определяется сразу после определения самих КПЭ.

Технические метрики могут использоваться для:

• Расчета значений КПЭ. Например, КПЭ «Средняя себестоимость обработки обращения» может рассчитываться на основании значений метрик по формуле (Себестоимость обработки оператором + Себестоимость обработки на портале самообслуживания + Себестоимость обработки на IVR) / 3.
• Детализации значений КПЭ в процессе поиска причин отклонений. Например, в процессе анализа причин увеличения значения КПЭ «Средняя себестоимость обработки обращения» может быть обнаружено существенное снижение значения метрики «Процент обслуженных вызовов на 1-м уровне». Это означает, что по каким-то причинам высококлассные (и высокооплачиваемые) специалисты 2-го уровня вынуждены заниматься решением типовых задач. Дальше анализируется почему это происходит (например, переход на поддержку новых продуктов не сопровождался достаточным обучением операторов 1-й линии) и ищутся пути решения.

К техническим метрикам, несомненно, относятся и приведенные выше в качестве примера псевдо-КПЭ показатели работы Call-центра. Пользователями технических метрик в основном являются менеджеры среднего и нижнего звеньев, которые разбираются с проблемами, приводящими к аномальным негативным изменениям общих КПЭ.

Во избежание двусмысленности и связанной с этим возможности искажения значений КПЭ в регламентах организации должны быть четко зафиксированы методики измерения технических метрик и расчета значений КПЭ на их основе.

И, наконец, о том, как может использоваться собранная информация со значениями КПЭ и технических метрик – завершающая стадия анализа эффективности, которому посвящена данная статья.

Вот основные варианты использования собранной информации:

• Сравнений значений КПЭ через определенные периоды времени — Что происходит?
• Анализ абсолютных значений КПЭ и технических метрик — Почему это происходит?
• Сравнение значений КПЭ «до» и «после» планируемого преобразования – Что должно будет произойти? Что же произошло на самом деле?
• Сравнение значений КПЭ компании с аналогичными показателями компаний-конкурентов (при наличии такой информации) – Что происходит у нас по сравнению с тем, что происходит у наших конкурентов?

Согласитесь – весьма актуальные вопросы для любого менеджера!

Заключение

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

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