Назад | Перейти на главную страницу

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

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

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

Итак, мои вопросы ... когда вы облажаетесь с приложением и вызовете простои:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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