Напрасно Вы так. Прозрачность и прогнозируемость финансовых отношений работодателя и работника дорого стоит. К тому же мы довольно сильно эволюционировали, если расположить нашу модель на шкале рыночных отношений, с одной стороны которой будет капитализм со звериным лицом (прям как по Марксу), а с другой скандинавская модель социализма, то мы гораздо ближе к скандинавам.
Индекс удовлетворенности клиента обслуживанием, показывает бизнесу насколько по мнению клиента то что он получил соответствует его ожиданиям. Этот индекс имеет практический смысл в отношении конкретного тикета. Интерпретация результатов зависит от методики расчета CSi, например у нас индекс больше 0,5 означает что по двум из трех метрик клиент оценил обслуживание как очень хорошее.
Будет ли он продолжать пользоваться услугами нашей компании наверняка сказать нельзя, но можно предположить что возможный “отток” будет связан с чем-то другим…
Охотно расскажу))
На ответы у “знающего ”инженера уходит минут пять чистого времени, может несколько больше если каких-то знаний нет. Все ответы, должны быть даны до конца смены.
Попробую более привести более очевидный пример иллюстрирующий пользу.
Уверен Вам приходилось сталкиваться не только с инцидентами, но и с RFS к примеру.
Представьте существенно изменился регламент выполнения какой-либо часто запрашиваемой операции, а следовательно хорошо знакомой инженерам операции. Инженер о изменении регламента не знает, причина сейчас не важна. Как следствие при выполнении этой операции происходит fuckup. Повезет если этот fuckup сразу себя проявит… а если нет, если ошибки будут накапливать пока не перерастут в инцидент.
Так вот, у нас все изменения регламентов ложатся на usecase, как только инженер выходит на смену — ему волей не волей приходится ознакомится с изменениями.
Вы правы, решить проблему клиента очень важно, это главный, но это как минимум не единственный KPI техподдержки.
Вероятно, Вы просто не сталкивались с проблемами которые нельзя “гуглить”.
Индекс CSi является KPI техподдержки. Влияние этого индекса на коммерческие KPI (CF, EBITDA итп) походу описывается даже не первой производной функции от многих переменных. Примерно такой же производной можно описать взаимосвязь цены и скорости легкового автомобиля.
Довольно сложно, но все же реально найти объективную взаимосвязь между CSi и коэффициентом оттока клиентов. Если рассматривать отток клиентов как “недополученную прибыль” то вот Вам и методика.
Э… Изменение метрик влияет на качество работы техподдержки… вроде все просто)
Качество — соответствие ожиданиям. Другое дело связь всегда нелинейная. Иными словами, можно наблюдать корреляцию трендов между ФОТ техподдержки и MTTR например, но однозначно утверждать что увеличение ФОТ на 1% приведет к снижению на 1% MTTR думаю никто серьезно не возьмется.
Структурированная и индексирована база знаний это прекрасно, думаю несогласных с этим тезисом не найдется.
Но все-же, по моему мнению хорошая техподдержка — это та техподдержка инженеры которой не просят подождать клиента пока они найдут и прочитают документ…
Не убедил? — тогда просто поверьте, есть ситуации когда нужно знать, а не искать.
PS Если Вы скажите — от таких услуг следует отказываться в техподдержке, я вероятно с Вами частично соглашусь, но бизнес — “не согласится”.
Я говорил иначе, а именно: “если строить “линии тренда”, то рост EKi совпадает с ростом CSi”, таким образом, корреляция линий трендов индексов как минимум есть. Что касается корреляции по месяцам EKi и CSi, то этот вопрос требует отдельного, углубленного изучения. Почему? — потому что период когда пользователь оставляет “обратную связь” не совпадает с периодом управления знаниями инженеров. Однако это совершенно точно за рамками моей статьи.
Usecase это обезличенные кейсы юзеров или типовые ситуации из реалий техподдержки. Usecase создаются одновременно при создании документов в нашей базе знаний, говоря иначе документ не добавляется в базу знаний без готовых usecase.
Все usecase апрувятся мною.
Что касается времени, то тут все субъективно, мой личный опыт — от 3 до 30 минут.
Вы правы полагаю, внедрение KM в коллцентрах и на первой линии ТП приносит максимально быстро существенные бенефиты. Насчет всего многообразия ИТ, мой опыт подсказывает внедрение KM целесообразно везде.
Почему?
Как Вы думаете если сотрудники в компании будут что называется “на одной волне” это повлечет увеличение эффективности работы компании в целом?
Мой ответ — да, за счет снижения издержек связанных с недостатком коммуникаций в коллективе (некоторые не знают специфики компании, кто-то не знает как работают коллеги, часть коллег вообще не подозревает о части услуг компании или о их изменении итп).
У меня нет экспертизы по KM в R&D, ответить Вам “цифрами” не готов. Из общих соображений, полагаю, эффективность разработки повысится при снижении издержек связанных с недостатком коммуникаций в коллективе (общими знаниями).
Я заглянул в статистику, статистические данные не коррелируют с “полутора годами” работы инженера ТП в компании. У нас если инженер продержался первый квартал у него хорошие шансы задержаться в лавке больше трех лет. Внутри ТП есть хорошие перспективы роста и этими перспективами пользуются.
Вы вопрос пожалуйста поточнее сформулируйте.
Сознательно упрощая “конструкцию”, для начала скажу так, плюсов у оклада ровно один — простота администрирования. Все остальное минусы
И feedback разный и диапазон комментариев от “горите в аду” до “дайте премию инженерам ТП”.
К сделке мы пришли от оклада. У оклада минусов гораздо больше imho.
Сделаю как при случае
Полагаю, что в большинстве случаев это справедливо.
Будет ли он продолжать пользоваться услугами нашей компании наверняка сказать нельзя, но можно предположить что возможный “отток” будет связан с чем-то другим…
На ответы у “знающего ”инженера уходит минут пять чистого времени, может несколько больше если каких-то знаний нет. Все ответы, должны быть даны до конца смены.
Уверен Вам приходилось сталкиваться не только с инцидентами, но и с RFS к примеру.
Представьте существенно изменился регламент выполнения какой-либо часто запрашиваемой операции, а следовательно хорошо знакомой инженерам операции. Инженер о изменении регламента не знает, причина сейчас не важна. Как следствие при выполнении этой операции происходит fuckup. Повезет если этот fuckup сразу себя проявит… а если нет, если ошибки будут накапливать пока не перерастут в инцидент.
Так вот, у нас все изменения регламентов ложатся на usecase, как только инженер выходит на смену — ему волей не волей приходится ознакомится с изменениями.
Вероятно, Вы просто не сталкивались с проблемами которые нельзя “гуглить”.
Довольно сложно, но все же реально найти объективную взаимосвязь между CSi и коэффициентом оттока клиентов. Если рассматривать отток клиентов как “недополученную прибыль” то вот Вам и методика.
Качество — соответствие ожиданиям. Другое дело связь всегда нелинейная. Иными словами, можно наблюдать корреляцию трендов между ФОТ техподдержки и MTTR например, но однозначно утверждать что увеличение ФОТ на 1% приведет к снижению на 1% MTTR думаю никто серьезно не возьмется.
Но все-же, по моему мнению хорошая техподдержка — это та техподдержка инженеры которой не просят подождать клиента пока они найдут и прочитают документ…
Не убедил? — тогда просто поверьте, есть ситуации когда нужно знать, а не искать.
PS Если Вы скажите — от таких услуг следует отказываться в техподдержке, я вероятно с Вами частично соглашусь, но бизнес — “не согласится”.
Все usecase апрувятся мною.
Что касается времени, то тут все субъективно, мой личный опыт — от 3 до 30 минут.
Почему?
Как Вы думаете если сотрудники в компании будут что называется “на одной волне” это повлечет увеличение эффективности работы компании в целом?
Мой ответ — да, за счет снижения издержек связанных с недостатком коммуникаций в коллективе (некоторые не знают специфики компании, кто-то не знает как работают коллеги, часть коллег вообще не подозревает о части услуг компании или о их изменении итп).