Илья Ничупиенко

Co-founder и CEO в Advascale

Как историю с проблемным клиентом превратить в импульс для развития компании: перестроить внутренние процессы, упорядочить условия сотрудничества и масштабироваться?

Как грамотно составить Service Level Agreement, чтобы предупредить возникновение конфликтных ситуаций, и как в целом выстраивать коммуникацию с заказчиками?

Своим опытом делится Co-founder и CEO в Advascale Илья Ничупиенко, который в свое время заполучил очень проблемного заказчика, повлиявшего на дальнейшую политику компании.

Начало этой истории вы можете найти здесь.

Обратите также внимание на другие статьи Kraftblick.Media по теме:

Service Level Agreement (SLA): самые важные условия, которые надо прописать IT компании.
Почему многие IT компании стремятся к модели оплаты Retainer или Time & Materials.
Как обезопасить компанию от оттока клиентов. Рекомендации IT менеджера с 30-летним бэкграундом.
Как общаться с клиентами, чтобы увеличить их Lifetime Value [кейсы Intspirit].

В статье вы прочитаете:

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

Какие пункты мы теперь прописываем в Service Level Agreement, чтобы обезопасить компанию

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

Теперь мы все это прописываем в Service Level Agreement и таким образом защищаем команду от целого ряда проблем.

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

1.Если клиент вмешивается в процесс создания продукта без согласования с нашей командой. Так мы не сможем отвечать за качество.

Допустим, мы что-то чиним, а клиент что-то чинит с другой стороны. Мы это не одобрили, известили его в письменной форме. Значит, с нас ответственность снята.

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

Это все равно что механик разобрал двигатель в машине, а ты сел и поехал на ней. Как думаете, далеко доберетесь?

2.Если клиент позволяет своим подрядчикам вмешиваться в неготовый продукт.

Например, кто-то от имени клиента начинает запускать пайплайны, которые нами еще не отстроены или даже не дописаны.