В последнее время у меня было много случаев простоя приложений, как от поставщиков, так и от моих собственных приложений. Это заставило меня задуматься, и насколько я могу судить по Google, на самом деле не существует хорошего или стандартного способа управления коммуникацией с клиентами во время инцидентов простоя.
Я видел, как это решалось многими способами.«вините всех, кроме нас»подход к«Мы облажались и нам жаль»подход.
Итак, у меня такие вопросы... когда вы допускаете ошибку в приложении и вызываете простой:
- Признаете ли вы вину немедленно? (Должны ли вы это делать с юридической точки зрения?)
- Какую информацию вы предоставляете клиенту относительно того, что пошло не так? («Проблема» или «Ошибка синтаксиса кода в одном из наших SQL-запросов»)
- Возвращаетесь ли вы с планом последующих профилактических мер или просто оставляете все как есть?
- Предоставляете ли вы обновления в режиме реального времени? Как часто? Через Twitter или общедоступный веб-сайт?
Есть ли еще какие-либо передовые методы, которые вы считаете успешными?
решение1
Вот что я делаю:
- Четко изложите, чтопоследствия(прямо сейчас и в ближайшем будущем). Выделите вероятные постоянные последствияили ее отсутствие(потеря данных, потеря рабочего времени).
- Сохраняйте тон очень нейтральным. Не тратьте энергию на обвинения/вину. В идеале это означает: «Я хочу дать вам информацию, но мое внимание требуется и в другом месте».
- Ваше уведомление будет отправлено многим людям, убедитесь, что ваш генеральный директор понимает суть первой половины абзаца. Обычно я предоставляю «исполнительное резюме». Технические детали могут предоставить справочную информацию другим техническим специалистам.
- Предоставьте контактные данные (предпочтительно человека, у которого есть время в разгар простоя) для дальнейших вопросов и попросите проявить терпение в том же предложении (это часто срабатывает).
- Обещаем обновления, когда ситуация изменится.
Отправляйте обновления, когда есть хорошие новости, перед закрытием офиса («все сотрудники продолжат работу ночью» — при необходимости учитывайте часовые пояса) и еще раз около времени открытия офиса.
Когда проблема будет решена (для любого определения этого слова), отправьте:
- Краткое изложение, включая сроки последствий
- Действия/изменения, предпринятые в краткосрочной перспективе и запланированные на будущее («извлеченные уроки»); основанные на:
- Технический анализ первопричин
Сохраняйте любые призывы к обвинению, чувству вины или линчеванию в отдельных письмах, желательно после некоторого времени ожидания.
Не обещайте ничего во время простоя, если вы не уверены, что действительно можете это сделать. Каким-то образом две отдельные ситуации с «плохими новостями» хуже, чем одна длинная.
Я предпочитаю использовать средство, при котором уведомление приходит на каждое сообщение (почта, Twitter, ..)
решение2
Самое важное, что я обнаружил и как поставщик услуг, и как пользователь услуг, это проактивная ответственность. Это не то, что вы говорите, а когда (как скоро) вы это говорите.
Если вас уведомили о том, что проблема возникла и была устранена (или над ней работают), это намного лучше, чем обнаружить проблему самостоятельно и попытаться связаться с поставщиком, чтобы выяснить, что, черт возьми, происходит. Это также помогает от игры в обвинения и экономит много времени на устранение неполадок (это мы или они?).
Что касается деталей, я считаю, что простое изложение того, что произошло, неплохо, если только пользователи специально не запросят больше информации. Найдутся люди, которые всегда хотят получить как можно больше подробностей, но большинство людей просто хотят, чтобы все работало (даже если это очень техническое).
Наконец, способность объяснить, какие шаги вы предприняли, чтобы подобное не повторилось, во многом способствует укреплению будущей доброжелательности и доверия.
решение3
Не имея более подробных сведений о вашем конкретном приложении, о том, как оно лицензируется, в какой сфере вы предоставляете услуги и т. д., невозможно ответить на ваши вопросы, не делая предположений.
- Обычно это путь признания собственных ошибок. Проконсультируйтесь с юристом, если в вашей сфере деятельности действуют многочисленные законы, соглашения об уровне обслуживания или скрупулезные контракты.
- Это тонкая грань между слишком большим и слишком малым количеством деталей. В общем, достаточно деталей, чтобы обычный пользователь чувствовал, что он понимает.
- Если это маленькая и быстро исправленная ошибка, не зацикливайтесь на ней. Если это был действительно большой промах, вам нужно будет заняться устранением последствий.
- Небольшие ошибки, уведомляйте, когда что-то не работает и когда это исправлено. Большие ошибки, уведомляйте, когда достигнуты какие-либо этапы решения.
Я предпочитаю, чтобы мои поставщики предоставляли слишком много информации о простоях. Но многие компании просто не могут или их застегивают юристы. Проконсультируйтесь со своим юристом/страховой компанией, если у вас есть какие-либо сомнения.