Як пояснити вихід третьої сторони продавця клієнтам англійською мовою
Learn how to communicate a service disruption in English when the root cause is a third-party vendor outage — being transparent without shifting blame or sounding evasive.
Якщо перерву в роботі спричинив сторонній постачальник — хмарний провайдер, процесор платежу, служба електронної пошти — ви все ще є власником відносин з клієнтом, навіть якщо ви не контролюєте виправлення. Зрозуміти англійську мова — це справа балансування: вам слід бути чесним щодо причини, не показуючи пальцем або не приховуючись за фразою « це не наша провина ». Цей посібник розповість вам, як чітко спілкуватися під час і після такого роду інциденту.
Ключовий словник
** Залежність від попереднього виконавця ** — служба сторонньої програми, на яку покладена ваша система, відмова якої може призвести до погіршення якості або невдачі вашої власної служби. “Наша система оплати залежить від платіжного процесора — коли їх API стало недоступним, помилки оплати стали наслідком.”
** Вплив на попередні версії** — вплив на ваших користувачів або системи, спричинений помилкою попередньої версії. “Вплив на наступний рівень був таким, що приблизно 15% спроб оформлення були невдалими протягом приблизно 40 хвилин.”
** Корінь проблеми (зовнішній) ** — вкажіть, що основна причина виникнення проблеми знаходиться за межами вашої системи, не використовуючи це як виправдання для уникнення відповідальності за поведінку користувача. “Головною причиною був відключення нашого хмарного постачальника електронної пошти — хоча ми не контролюємо їхню інфраструктуру, ми відповідальні за те, як наша система грациозно справляється з такими помилками.”
** Граціозне зниження якості ** — розробка системи таким чином, щоб у разі невдачі залежності, деякі функції все ще працювали, замість того, щоб все зазнало повної невдачі.
- “З- за елегантного зниження якості, користувачі все ще могли здійснювати покупки за допомогою збережених способів оплати, навіть якщо служба перевірки нових карток була не працює.” *
** Елементи дій після інциденту ** — конкретні дії, які ваша команда робить у результаті інциденту, навіть якщо причина була зовнішньою, що показує, що ви не просто чекаєте, поки постачальник виправить ситуацію і перейде до наступного кроку.
Під час інциденту
- “Ми зараз переживаємо перерву в обслуговуванні, спричинену відмовою одного з наших постачальників інфраструктури. Наша команда активно моніторить ситуацію і працює над зменшенням ризиків»
- «Хоча основна проблема полягає в сторонній службі, від якої ми залежимо, ми розуміємо, що вплив на вас є однаковим незалежно від причини — ми ставимося до цього з повним пріоритетом»
- «Ми ще не маємо ETA від виробника, але ми опублікуємо оновлення протягом години незалежно від того, чи змінилася ситуація»
Пояснення після резолюції
- «Перерва в обслуговуванні між 2:14 і 2:53 сьогодні була викликана відключенням [виробника], що вплинуло на нашу здатність обробляти нові реєстрації в цей час»
- “Хоча ми не можемо контролювати інфраструктуру нашого постачальника безпосередньо, ми реалізуємо резерв, щоб майбутній відключення цього конкретного постачальника не призведе до повного переривання обслуговування.”
- «Ми беремо на себе відповідальність за вплив, який ви пережили, навіть якщо коренева причина була зовнішньою — ось що ми робимо, щоб зменшити радіус вибуху подібної події в майбутньому»
Не слід плутати з мовою мовлення
- Уникайте: «Це було повністю через невдачу нашого постачальника і поза нашим контролем.» → Надає перевагу: «Головною причиною був відключення нашого постачальника інфраструктури. Ми відповідальні за стійкість нашої системи незалежно від того, і ми робимо зміни, щоб зменшити вплив будь-якого одного часу простою виробника»
- Уникайте: «Ми не могли нічого зробити». → Надаєте перевагу: «Ми не мали резервного варіанту для цієї конкретної залежності — ми додаємо його, щоб подібна подія мала менший вплив наступного разу»
- Уникайте мовчазності доки виробник не виправить ситуацію → Віддавайте перевагу: активним оновленням вашого власного розслідування та зусиль з усунення, навіть у той час, коли ви чекаєте на виробника.
Професійні поради
- ** Назви постачальника, тільки якщо ваш договір і юридична команда дозволяють це. ** У деяких повідомленнях про інциденти вкажіть ім’ я третьої сторони, в інших залиште його загальним (« постачальник інфраструктури ») — перевірте правила вашої компанії перед публікацією.
- ** Завжди поєднуйте «зовнішню причину» з «внутрішньою відповідальністю». ** Замовникам байдуже, хто винен технічно — їм байдуже, чи ви берете на себе відповідальність за досвід.
- **Підтримуйте конкретні поліпшення стійкості, а не просто вибачення. ** “Ми додали резервну копію для цієї залежності” набагато більш заспокоює, ніж “ми вибачаємося, це не повториться”
Практичні вправи
- Напишіть оновлення про інцидент з двома реченнями, пояснюючи перерву в роботі, спричинену відмовою сторонньої сторони, не звучачи так, ніби ви ухиляєтеся від відповідальності.
- Переписати це речення, щоб звучало більш відповідально: «Це була повна провина продавця, і ми не могли нічого зробити»
- Написати коротке резюме після інциденту, в якому описується одне поліпшення стійкості, яке ви робите після відключення постачальника.
Зв’язані ресурси
- Як пояснити перерву в виробництві клієнтам англійською мовою
- Як написати пост-інциденту електронну пошту клієнта англійською мовою
- Як написати англійською мовою оновлення стану явного інциденту
Перекладач: Володимир Сікорський; переклади: Володимир Сікорський
Комунікація про перерву в роботі, спричинену стороннім постачальником, ефективно вимагає точності і емпатії. Легко потрапити в пастку нечітких пояснень, технічного жаргону, який затьмарює проблему, або – найгірше з усього – підступно звинувачувати продавця. Метою завжди є прозорість, визнання впливу і демонстрація активних кроків. Давайте уточним, как вы выражаете эту ситуацию, особенно сосредоточившись на лингвистических нюансах, которые резонируют с профессиональной аудиторией.
Поширеною помилкою є надмірне використання пасивного голосу. Замість того, щоб сказати « База даних була недоступною через проблему з постачальником », розгляньте щось на зразок: « Ми пережили перерву, що вплинула на доступність бази даних після переривання нашого постачальника обробки даних. Наша команда негайно розпочала діагностику і зв’язалася з постачальником, щоб зрозуміти кореневу причину. ” Зауважте зміну - це пряме, зосереджене на * вашій * відповіді, і уникайте визначення постачальника як єдиного відповідального. Це не про звинувачення, це про право власності на комунікацію.
Іншим ключовим елементом є передбачення питань. Коментар перегляду коду може звучати так: “ Investigate potential race conditions in our data access layer – could this be related to the vendor’s recent update? ” Це розумна занепокоєність, але формулювання її як «може це бути пов’ язано» демонструє ретельний аналіз, а не негайне вказування пальцем. Аналогічно, у повідомленні Slack, адресованому користувачам, уникайте фраз на кшталт «У постачальника є проблеми». Замість цього спробуйте: «Ми зараз розслідуємо проблему, що впливає на [назва служби] і відчуваємо перерване з’ єднання. Ми тісно співпрацюємо з нашим провайдером, щоб якомога швидше відновити повний функціонал. Оновлення буде опубліковано тут. » Цей спосіб безпосередньо підтверджує існування проблеми, надає вам графік (навіть якщо він не є остаточним) і повторює співпрацю.
Нарешті, пам’ятайте, що документація - особливо описи PR - вимагає трохи більш формального тону. Хороший приклад: « Через непередбачений відключення нашої сторонньої служби збагачення даних, [Назва служби] зараз відчуває погіршення продуктивності. Наша команда інженерів впровадила тимчасові рішення у [пошкодженій області] і співпрацює з виробником з метою постійного вирішення проблеми. Ми очікуємо повного відновлення до [часовий проміжок], хоча це може змінюватися залежно від оновлень виробника». Цей пункт чітко визначає вплив, описує виконані дії і керує очікуваннями щодо часового проміжку. Сфокусування на спільному вирішенні проблем підсилює активний підхід вашої команди.