Как управлять связью во время простоя приложения?

В последнее время у меня было много опыта с простоями приложений, как от поставщиков, так и от моих собственных приложений. Это заставляет меня задуматься, и, насколько я могу, я не могу найти хорошего или стандартного способа управления взаимодействием с клиентами во время простоев.

Я видел, что это обрабатывается многими способами от подхода «обвиняй всех, кроме нас» до подхода «мы облажались и нам жаль» .

Так что мои вопросы ... когда вы портите приложение и вызываете простои:

1. Вы признаете вину немедленно? (Должны ли вы, по закону?)
2. Сколько информации вы даете клиенту относительно того, что пошло не так? («Проблема» и «Ошибка синтаксиса кода в одном из наших SQL-запросов»)
3. Вы возвращаетесь с планом последующей профилактики или просто оставляете его в «Это решено»?
4. Предоставляете ли вы обновления в реальном времени? Как часто? Через Twitter или публичный сайт?

Какие еще лучшие практики для этого вы нашли успешными?

Вот что я делаю:

• Четко сформулируйте, каковы последствия (прямо сейчас и в ближайшем будущем). Выделите вероятные постоянные последствия или их отсутствие (потеря данных, потеря рабочих часов).
• Держите тон очень нейтральным. Не тратьте энергию на вину / вину. В идеале это говорит: «Я хочу дать вам информацию, но мое внимание также необходимо в другом месте».
• Ваше уведомление будет переслано многим людям, убедитесь, что ваш генеральный директор понимает суть в первой половине абзаца. Обычно я даю резюме. Технические детали могут предоставить справочную информацию другим техническим специалистам.
• Предоставьте контактную информацию (желательно кого-то, у кого есть время в разгар простоя) для дальнейших вопросов и попросите терпения в том же предложении (это работает часто).
• Обещайте обновления, когда ситуация изменится.

Присылайте обновления, когда есть хорошие новости, до закрытия офиса («весь персонал будет работать всю ночь» - при необходимости укажите часовые пояса) и снова около времени открытия офиса.

Когда проблема будет решена (для любого определения этого слова), отправьте:

• Резюме, включая сроки последствий
• Действия / изменения, предпринятые в краткосрочной перспективе и запланированные на будущее («извлеченные уроки»); основанный на:
• Технический анализ первопричин

Сохраняйте любые призывы к обвинению, вине или линчеванию в отдельных письмах, желательно после некоторого времени восстановления.

Не совершайте никаких действий во время простоя, если вы действительно, действительно уверены, что сможете это сделать. Каким-то образом две отдельные ситуации «плохих новостей» хуже длинных.

Я предпочитаю использовать носитель, где уведомление отправляется на каждое сообщение (почта, Twitter, ..)

Самая важная вещь, которую я нашел и как поставщик услуг, и как пользователь сервиса, - это проактивная ответственность. Это не в состоянии, что вы говорите, но когда (как скоро) вы говорите это.

Если вы получили уведомление о том, что проблема возникла и была устранена (или над ней ведется работа), это намного лучше, чем обнаружить ее самостоятельно и попытаться связаться с продавцом, чтобы выяснить, что происходит в мире. Это также помогает в игре по обвинению и экономит много времени на устранение неполадок (это мы или они?).

Что касается подробностей, я считаю, что давать простое краткое изложение того, что произошло, было бы хорошо, если бы пользователи специально не запрашивали дополнительную информацию. Будут некоторые люди, которые всегда хотят получить как можно больше деталей, но большинство людей просто хотят, чтобы все работало (даже если они очень технические).

Наконец, возможность объяснить, какие шаги вы предприняли, чтобы этого больше не повторилось, в значительной степени поможет будущей доброй воле и доверию.

Не зная гораздо больше о вашем конкретном приложении, о том, как оно лицензируется, о сфере предоставления услуг и т. Д .; невозможно ответить на ваши вопросы, не угадав.

1. Владение своими собственными ошибками - обычно путь. Проконсультируйтесь со своим адвокатом, если в вашей области действуют многие законы, SLA или тщательные контракты.
2. Это тонкая грань между слишком много и слишком мало деталей. В целом достаточно подробностей, чтобы обычному пользователю казалось, что он понимает.
3. Если это маленькая и быстро исправленная ошибка; не зацикливайся на этом. Если это был действительно большой провал, у вас есть контроль повреждений.
4. Небольшие ошибки, сообщите, когда он не работает и когда это исправлено. Большие ошибки, сообщите, когда будут достигнуты какие-либо вехи в решении.

Я предпочитаю, чтобы мои поставщики предоставляли слишком много информации о простоях. Но многие предприятия просто не могут, или их запугивают юристы. Проконсультируйтесь со своим адвокатом / страховкой, если у вас есть какие-либо сомнения.