Мне кажется, здесь ключевая проблема не только в самой цифре “4 часа”, а в том, как её потом проговаривают клиенту.
В хорошей схеме я бы разделял три вещи:
время реакции — “мы увидели и взяли в работу”;
ETA for ETA — “когда дадим первую осмысленную оценку”;
целевой срок восстановления — уже после диагностики, с оговорками по внешним зависимостям.
Иначе SLA превращается в источник ложных обещаний: поддержка формально хочет успокоить клиента, но по факту обещает срок раньше, чем команда вообще поняла причину. Мне кажется, многие конфликты вокруг SLA начинаются именно в этой коммуникационной дырке, а не в договоре.
Хороший кейс. Особенно зацепило ETA for ETA: клиенту часто важнее предсказуемость, чем обещание “починим как можно быстрее”.
Мне кажется, рядом с Zero Bug Policy полезен weekly review не только багов, но и клиентских диалогов вокруг них: где Support/CSM пообещал срок раньше уверенности, где клиент не понял следующий шаг, где won't fix прозвучал как “мы вас бросили”, хотя процессно всё корректно.
Вы отдельно смотрели качество коммуникации Support/CSM после внедрения политики — consistency формулировок, обещания сроков, reopen/repeat cases? Или due dates + SLA оказалось достаточно?
Мне кажется, здесь ключевая проблема не только в самой цифре “4 часа”, а в том, как её потом проговаривают клиенту.
В хорошей схеме я бы разделял три вещи:
время реакции — “мы увидели и взяли в работу”;
ETA for ETA — “когда дадим первую осмысленную оценку”;
целевой срок восстановления — уже после диагностики, с оговорками по внешним зависимостям.
Иначе SLA превращается в источник ложных обещаний: поддержка формально хочет успокоить клиента, но по факту обещает срок раньше, чем команда вообще поняла причину. Мне кажется, многие конфликты вокруг SLA начинаются именно в этой коммуникационной дырке, а не в договоре.
Хороший кейс. Особенно зацепило
ETA for ETA: клиенту часто важнее предсказуемость, чем обещание “починим как можно быстрее”.Мне кажется, рядом с Zero Bug Policy полезен weekly review не только багов, но и клиентских диалогов вокруг них: где Support/CSM пообещал срок раньше уверенности, где клиент не понял следующий шаг, где
won't fixпрозвучал как “мы вас бросили”, хотя процессно всё корректно.Вы отдельно смотрели качество коммуникации Support/CSM после внедрения политики — consistency формулировок, обещания сроков, reopen/repeat cases? Или due dates + SLA оказалось достаточно?