Làm thế nào để quản lý giao tiếp trong thời gian ngừng ứng dụng?

Gần đây tôi đã có rất nhiều kinh nghiệm với thời gian ngừng hoạt động của ứng dụng, từ cả nhà cung cấp và ứng dụng của riêng tôi. Điều này khiến tôi suy nghĩ và tốt nhất tôi có thể google không thực sự là một cách tốt hay tiêu chuẩn để quản lý giao tiếp khách hàng trong các sự cố thời gian chết.

Tôi đã thấy điều này xử lý rất nhiều cách từ cách tiếp cận "đổ lỗi cho tất cả mọi người trừ chúng tôi" đến cách tiếp cận "chúng tôi đã làm hỏng và chúng tôi xin lỗi" .

Vì vậy, câu hỏi của tôi là ... khi bạn làm hỏng ứng dụng và gây ra thời gian chết:

1. Bạn có nhận lỗi ngay lập tức không? (Bạn có nên hợp pháp không?)
2. Bao nhiêu thông tin bạn cung cấp cho khách hàng về những gì đã sai? ("Sự cố" so với "Lỗi cú pháp mã trong một trong các truy vấn SQL của chúng tôi")
3. Bạn có quay lại với một kế hoạch phòng ngừa tiếp theo, hoặc chỉ để lại tại "điều này đã được giải quyết"?
4. Bạn có cung cấp cập nhật theo thời gian thực? Bao lâu? Thông qua Twitter hoặc trang web công khai?

Bất kỳ thực hành tốt nhất nào khác cho việc này mà bạn thấy thành công?

Đây là những gì tôi làm:

• Nêu rõ những hậu quả là gì (ngay bây giờ và trước mắt). Làm nổi bật các hậu quả có thể xảy ra vĩnh viễn hoặc thiếu nó (mất dữ liệu, mất giờ nhân viên).
• Giữ giọng rất trung tính. Đừng dành năng lượng cho việc đổ lỗi / tội lỗi. Lý tưởng nhất là truyền tải "Tôi muốn cung cấp cho bạn thông tin nhưng sự chú ý của tôi cũng cần thiết ở nơi khác".
• Thông báo của bạn sẽ được chuyển đến nhiều người, hãy chắc chắn rằng CEO của bạn hiểu ý chính trong nửa đoạn đầu tiên. Thông thường tôi cung cấp một 'bản tóm tắt điều hành'. Chi tiết kỹ thuật có thể cung cấp thông tin cơ bản cho những người kỹ thuật khác.
• Cung cấp chi tiết liên lạc (tốt nhất là người có thời gian chờ đợi) để biết thêm câu hỏi và yêu cầu sự kiên nhẫn trong cùng một câu (điều này thường hoạt động).
• Hứa hẹn cập nhật khi tình hình thay đổi.

Gửi thông tin cập nhật khi có tin tốt, trước giờ đóng cửa văn phòng ("tất cả nhân viên sẽ tiếp tục qua đêm" - tài khoản cho các múi giờ nếu cần thiết) và một lần nữa vào khoảng thời gian mở văn phòng.

Khi vấn đề được giải quyết (đối với bất kỳ định nghĩa nào của từ đó), hãy gửi:

• Một bản tóm tắt bao gồm thời gian của hậu quả
• Các hành động / thay đổi được thực hiện trong thời gian ngắn và được lên kế hoạch cho tương lai ("bài học kinh nghiệm"); dựa trên:
• Phân tích nguyên nhân gốc kỹ thuật

Giữ bất kỳ cuộc gọi nào để đổ lỗi, cảm giác tội lỗi hoặc nới lỏng trong các thư riêng biệt, tốt nhất là sau một thời gian hồi chiêu.

Không cam kết với bất cứ điều gì trong thời gian chết trừ khi bạn thực sự, thực sự chắc chắn rằng bạn có thể cung cấp. Bằng cách nào đó hai tình huống "tin xấu" riêng biệt tồi tệ hơn một tình huống dài.

Tôi thích sử dụng một phương tiện trong đó thông báo được đẩy trên mỗi tin nhắn (mail, Twitter, ..)

Điều quan trọng nhất tôi đã tìm thấy cả với tư cách là nhà cung cấp dịch vụ và người sử dụng dịch vụ là trách nhiệm chủ động. Nó không thể nói những gì bạn nói, nhưng khi nào (bao lâu nữa) bạn nói nó.

Nếu bạn được thông báo rằng đã xảy ra sự cố và đã được khắc phục (hoặc đang được khắc phục), sẽ tốt hơn nhiều so với việc tự mình khám phá vấn đề và cố gắng liên hệ với nhà cung cấp để tìm hiểu chuyện gì đang xảy ra trên thế giới. Nó cũng giúp với trò chơi đổ lỗi và tiết kiệm rất nhiều thời gian khắc phục sự cố (là chúng tôi hay là chúng?).

Theo như chi tiết, tôi thấy rằng việc đưa ra một bản tóm tắt đơn giản về những gì đã xảy ra là tốt trừ khi người dùng đặc biệt yêu cầu thêm thông tin. Sẽ có một số người luôn muốn có nhiều chi tiết nhất có thể, nhưng hầu hết mọi người chỉ muốn mọi thứ hoạt động (ngay cả khi họ có kỹ thuật cao).

Cuối cùng, việc có thể giải thích những bước bạn đã thực hiện để điều đó sẽ không xảy ra một lần nữa đi một chặng đường dài hướng tới thiện chí và niềm tin trong tương lai.

Không biết nhiều về ứng dụng cụ thể của bạn, cách nó được cấp phép, lĩnh vực bạn cung cấp dịch vụ, v.v; không thể trả lời câu hỏi của bạn mà không cần đoán.

1. Sở hữu những sai lầm của riêng bạn thường là con đường. Tham khảo ý kiến ​​luật sư của bạn nếu lĩnh vực của bạn là một trong đó áp dụng nhiều luật, SLA hoặc hợp đồng tỉ mỉ.
2. Đó là một ranh giới giữa quá nhiều và quá ít chi tiết. Nói chung đủ chi tiết mà một người dùng thông thường sẽ cảm thấy như họ hiểu.
3. Nếu đó là một lỗi nhỏ và nhanh chóng sửa chữa; đừng nghĩ về nó Nếu đó là một vấn đề rất lớn, bạn phải kiểm soát thiệt hại.
4. Những lỗi nhỏ, thông báo khi nó xuống và khi nó được sửa. Những sai lầm lớn, thông báo khi bất kỳ cột mốc nào cho giải pháp đã đạt được.

Tôi thích các nhà cung cấp của tôi cung cấp quá nhiều thông tin về thời gian chết. Nhưng nhiều doanh nghiệp không thể hoặc họ bị các luật sư nén lại. Tham khảo ý kiến ​​luật sư / bảo hiểm của bạn nếu bạn có bất kỳ nghi ngờ nào.