Size: a a a

2020 October 14

O

Onlinehead in ctodailychat
Вообще, можно сразу изначально прям делать все на очередях, которые разгребает каждый уровнь с ассайном на группу и дежурными «разгребателями» в каждой команде девелоперов. Это обычно +- неплохо работает.
источник

O

Onlinehead in ctodailychat
По крайней мере оно предсказуемо, формализуемо, нет тупых обидок про «че ты на меня опять говно повесил от кастомера, у меня тут своего достаточно» и вот этого всего. И точно понятно где оно зависло и что дальше.
источник

O

Onlinehead in ctodailychat
Бонусом в такой структуре получишь базу знаний, настроенное взаимодействие между командами в части «что поменялось», скорее всего всплывет недостаток инструментов и проявится бас-фактор во многих местах. Ну и конечно возможность написать на сайте SLA саппорта и возможность его соблюдать. И главное - контролировать что он соблюдается. Главное поймать момент, когда тикеты будут массово гулять в эскалацию и долбить всех про «что тебе не хватало, чтобы самому решить этот тикет». Весьма часто оказывается, что знания (глобально) не так важны и нужна была просто документация\тулинг\права\что-то еще, что можно достаточно просто решить. Ну и девелоперы возможно начнут на это по-другому смотреть, ведь никому не хочется разгребать всякое тупое от кастомеров, которое летит просто потому, что лень доку писать\нет интерфейсов и т.д.
источник

O

Onlinehead in ctodailychat
Короче, организация саппорта - это интересно:)
источник

MS

Max Syabro in ctodailychat
Onlinehead
Сапорт - конвейер, причём часто с не очень понятными вводными, которые ты хер запланируешь (ну если ты конечно сознательно куски продукты не ломает). И в этом конвейере желательно иметь SLA, чёткую логику кто за что отвечает и и так далее. Одном из артефактов конвейера может быть что-то в бэклог для аджайл команды, или коррекция приоритетов или что угодно еще с этой стороны, но сам процесс - он waterfall.
#fomo
источник

O

Onlinehead in ctodailychat
Onlinehead
Более того, когда строишь саппорт, нужно закладываться по методологии так, чтобы у тебя квалификация саппорта (возможная) была как можно ниже. Чем дальше в лес, тем больше будет тикетов, тем больше нужно будет людей и тем сложнее будет их нанимать и тем дороже они будут. Всякие нечеткие методологии, построенные на тайных знаниях и интуиции так себе масштабируются и требуют людей с нормальной квалификацией, которые будут во всем этом многообразии ориентироваться.
Про квалификацию есть кстати весьма интересная особенность - чем более скилованых людей ты будешь туда сажать - тем больше проблем в дальнейшем ты огребешь. То есть на первом этапе да, там нужны нормальные инженеры, но их единственная цель должна быть сделать так, чтобы они стали не нужны и ушли на повышение. Иначе может создаться иллюзия что с саппортом все в порядке, все разгребается успешно, а на самом деле оно летит на скилах пары человек, которые там непонятно как случайно оказались. А работа там сжигает людей достаточно быстро, после чего все внезапно разваливается и получается грустная печалька. И в итоге весьма дорогая, да, потому что сознательно в уже работающий саппорт засунуть хорошего инженера для разгребания всего-всего или совсем нельзя, или можно, но очень дорого и временно, потому что он тоже сгорит. Поэтому засунуть его туда будет можно только в варианте «сделай так чтобы ты был не нужен, а потом пойдёшь с повышением куда-то», и это «куда-то» еще придумать придётся, потому что скил будет весьма специфичный и вообще не дай бог ему понравится, будет бас-фактор близкий к единице:)
источник

A

Alexander in ctodailychat
Onlinehead
Сапорт - конвейер, причём часто с не очень понятными вводными, которые ты хер запланируешь (ну если ты конечно сознательно куски продукты не ломает). И в этом конвейере желательно иметь SLA, чёткую логику кто за что отвечает и и так далее. Одном из артефактов конвейера может быть что-то в бэклог для аджайл команды, или коррекция приоритетов или что угодно еще с этой стороны, но сам процесс - он waterfall.
золотые слова. Вообще у меня опыт в постройке саппорта другого рода, но процесс надо отстраивать и тюнить под конкретику. У меня был провайдер на 3к+ клиентов, когда я начал отстраивать систему саппорта. Вкратце, она сама не юстировалась, т.к. проблемы могли эскалироваться до сетевых инженеров и падать на монтажников. Сетевым инженерами мониторить метрики всегда было влом, монтажники за подключение новых абонентов получали больше чем за ремонт линий у старых. Пришлось ввести KPI на висящие тикеты для инженеров, макисимальный срок решения тикета и ввести дежурную монтажную бригаду, которая занималась только ремонтами всю смену и получала фиксу. А затыков пока все не формализовалось было море 🙂
источник

O

Onlinehead in ctodailychat
Alexander
золотые слова. Вообще у меня опыт в постройке саппорта другого рода, но процесс надо отстраивать и тюнить под конкретику. У меня был провайдер на 3к+ клиентов, когда я начал отстраивать систему саппорта. Вкратце, она сама не юстировалась, т.к. проблемы могли эскалироваться до сетевых инженеров и падать на монтажников. Сетевым инженерами мониторить метрики всегда было влом, монтажники за подключение новых абонентов получали больше чем за ремонт линий у старых. Пришлось ввести KPI на висящие тикеты для инженеров, макисимальный срок решения тикета и ввести дежурную монтажную бригаду, которая занималась только ремонтами всю смену и получала фиксу. А затыков пока все не формализовалось было море 🙂
Знакомая тема:) Я тоже у провайдера делал. Масштаб чуть побольше, только на мне еще кол-центр был. И монтажники были подрядной организацией...
источник

A

Alexander in ctodailychat
Onlinehead
Знакомая тема:) Я тоже у провайдера делал. Масштаб чуть побольше, только на мне еще кол-центр был. И монтажники были подрядной организацией...
колл-центр я заигнорил  в истории, хотя с ним тоже секса хватало ввиду чрезвычайно низкого уровня подготовки операторов
источник

O

Onlinehead in ctodailychat
Но оттуда я честно говоря почти ничего не помню, это было давно, весьма сложно и больше проблем было с телефонией на заббиксе:)
источник

O

Onlinehead in ctodailychat
Alexander
колл-центр я заигнорил  в истории, хотя с ним тоже секса хватало ввиду чрезвычайно низкого уровня подготовки операторов
Ох... да, операторы. И тулинг.
источник

A

Alexander in ctodailychat
А сейчас классно! Повесил голосового бота, он стандартную схему прогоняет, абонента сам определяет, тикет сам создаёт. Красота.
источник

V

Vitaly in ctodailychat
Alexander
А сейчас классно! Повесил голосового бота, он стандартную схему прогоняет, абонента сам определяет, тикет сам создаёт. Красота.
ненавижу голосовых ботов
источник

MS

Max Syabro in ctodailychat
Vitaly
ненавижу голосовых ботов
никто не любит как клиент
но мы сейчас про бизнес же
источник

V

Vitaly in ctodailychat
Max Syabro
никто не любит как клиент
но мы сейчас про бизнес же
да, я понимаю. но промолчать не смог, каждый раз больно как вспоминаю об их существовании)
источник

A

Alexander in ctodailychat
Vitaly
ненавижу голосовых ботов
я тоже, но их неправильно готовят и не там применяют.
источник

V

Vitaly in ctodailychat
и каждый раз молюсь о том, чтобы фраза "позови человека" или "позови оператора" была забиндена и четко распознавалась)
источник

MS

Max Syabro in ctodailychat
Alexander
я тоже, но их неправильно готовят и не там применяют.
а есть примеры хорошей готовки? я не видел :(
источник

MS

Max Syabro in ctodailychat
Vitaly
и каждый раз молюсь о том, чтобы фраза "позови человека" или "позови оператора" была забиндена и четко распознавалась)
"ОПЕРАТОР БЛЯДЬ" обычно работает
источник

A

Alexander in ctodailychat
Max Syabro
а есть примеры хорошей готовки? я не видел :(
ну у оператора ПД можно хороший сценарий построить.
источник