Як зберегти ланцюжки електронних листів, коли листи стають заявками
Збереження ланцюжка електронного листування після перетворення листа на тікет залежить від правил об’єднання в ланцюжки, які використовує хелпдеск. До поширених сигналів належать заголовки Message-ID, In-Reply-To і References. Деякі платформи також використовують ID тікета або інший ідентифікатор у тілі повідомлення чи адресі отримувача.
Скористайтеся цим контрольним списком, перш ніж покладатися на новий канал електронної пошти:
- Підключіть адресу служби підтримки за допомогою методу, який офіційно підтримує хелпдеск.
- Надішліть тестовий тікет і дайте відповідь через той самий маршрут, яким користуватимуться клієнти.
- Порівняйте заголовки оригінального повідомлення та відповіді, а потім переконайтеся, що відповідь з’явилася в наявному тікеті.
Якщо під час тесту створюється новий тікет, перевірте задокументовані правила об’єднання в ланцюжки вашого хелпдеску, перш ніж змінювати маршрутизацію пошти. Кожна платформа може по-різному комбінувати заголовки, ідентифікатори тікетів і перевірки відправника.
Ключові висновки
Об’єднання електронних листів у ланцюжки ґрунтується не лише на темах повідомлень. Хелпдески зазвичай перевіряють стандартні заголовки відповідей і можуть використовувати власні ідентифікатори тікетів як додаткові сигнали для зіставлення.
| Пункт | Деталі |
|---|---|
| Заголовки пов’язують відповіді | In-Reply-To і References вказують на ID повідомлень із наявного листування. |
| Правила залежать від платформи | Хелпдеск також може перевіряти ID тікета, прихований ідентифікатор, адресу отримувача або відправника. |
| Використовуйте підтримувані підключення | Дотримуйтеся налаштувань поштової скриньки, задокументованих вашим хелпдеском і постачальником електронної пошти. |
| Тестуйте реальний маршрут | Дайте відповідь як клієнт і переконайтеся, що повідомлення приєдналося до оригінального тікета. |
| Варіанти поштових скриньок Deskhero | Deskhero підтримує двосторонні підключення поштових скриньок Google і Microsoft, а також пересилання з домену з автентифікованим надсиланням. |
Зміст
- Які заголовки насправді зберігають ланцюжки електронного листування
- Налаштування поштових серверів для збереження цілісності ланцюжків
- Чому ланцюжки перериваються та як виправити кожну причину
- Як Deskhero зберігає історію листування цілісною
- У чому більшість посібників із налаштування помиляється
- Запустіть хелпдеск із ланцюжками, не втративши жодної відповіді
- Джерела
- Поширені запитання
Які заголовки насправді зберігають ланцюжки електронного листування
Зазвичай електронний лист має Message-ID. Відповідь може містити значення In-Reply-To, яке вказує на повідомлення, на яке дають відповідь, а також значення References зі списком ID попередніх повідомлень. Хелпдеск може використовувати ці зв’язки, щоб пов’язувати повідомлення з листуванням. Документація Amazon Connect описує як хронологічні ланцюжки, так і деревоподібні структури, що виникають, коли хтось відповідає на старіше повідомлення.
Платформи можуть додавати власні методи зіставлення. Zendesk документує три перевірки: елементи заголовків, закодований ID у тілі повідомлення та закодований ID в адресі отримувача Zendesk. Це специфічні правила Zendesk, а не шаблон, який можна скопіювати в кожен хелпдеск.
Об’єднання в ланцюжки важливе, оскільки відокремлення відповіді від попередніх повідомлень ускладнює відстеження історії підтримки:
- Користувачам може знадобитися шукати попередні вкладення або рішення в іншому тікеті.
- Отримувачі та попередні відповіді можуть бути відокремлені від останнього запитання.
- Двоє користувачів можуть відповідати на пов’язані повідомлення, не усвідомлюючи, що вони належать до одного листування.
Документація Freshdesk щодо електронної пошти показує інший підхід, специфічний для платформи. Вона перевіряє ID тікета, ID повідомлення або унікальний ідентифікатор, а потім — відправника. Практичний висновок полягає в тому, щоб з’ясувати, які сигнали використовує саме ваш хелпдеск, і зберігати їх під час фактичного проходження пошти.
Налаштування поштових серверів для збереження цілісності ланцюжків
Надійне налаштування починається з методу підключення, який підтримує хелпдеск. Не припускайте, що SMTP-реле, правило пересилання або синхронізація поштової скриньки працюватимуть однаково в різних продуктах.
- Виберіть задокументоване підключення поштової скриньки. Якщо хелпдеск пропонує пряме підключення Google або Microsoft, скористайтеся його процесом авторизації. Якщо потрібне пересилання, використовуйте точну адресу призначення та DNS-записи, надані продуктом.
- Налаштуйте пересилання для потрібної адреси. У посібнику Deskhero з пересилання в Google Workspace пояснюється, як створити групу та додати адресу призначення Deskhero як учасника. Microsoft 365 та інші постачальники мають інші шляхи налаштування.
- Не змінюйте ідентифікатори платформи. Якщо ваш хелпдеск додає маркер тікета до вихідного сповіщення, не видаляйте його з шаблону, якщо в документації продукту не зазначено, що він необов’язковий. Freshdesk рекомендує додавати формат ID тікета, тоді як Zendesk за замовчуванням додає закодований ID до вихідних сповіщень.
- Перевірте системи, які змінюють пошту. Правила маршрутизації, списки розсилки та шлюзи можуть змінити повідомлення до того, як його отримає хелпдеск. Порівнюйте необроблене джерело на кожному доступному етапі, а не вгадуйте, де змінилося значення.
- Проведіть повторюваний перевірочний тест. Створіть тікет, надішліть відповідь і перегляньте необроблене джерело. Перевірте, чи вказує
In-Reply-Toна попереднійMessage-ID, чи міститьReferencesочікуваний ланцюжок і чи приєдналася відповідь до наявного тікета.
Порада: Тестуйте через ту саму адресу, шлях пересилання та поштовий клієнт, якими користуватимуться ваші клієнти. Пряме повідомлення на внутрішню тестову адресу не перевіряє весь робочий маршрут.
Чому ланцюжки перериваються та як виправити кожну причину
Відповідь може стати новим тікетом із кількох причин. Точна причина залежить від правил зіставлення платформи.
- Відсутні заголовки відповіді. Повідомлення, створене як новий електронний лист, може не містити значень
In-Reply-ToабоReferences, які очікуються у відповіді. Попросіть відправника скористатися функцією «Відповісти», а потім порівняйте необроблене джерело. - Змінено маршрутизацію або отримувачів. Повідомлення, надіслане на іншу адресу служби підтримки, може створити інший тікет. Наприклад, Freshdesk документує особливу поведінку, коли вказано більше однієї налаштованої адреси хелпдеску.
- Видалено ідентифікатор платформи. Редагування шаблону сповіщення може видалити ID тікета або прихований ідентифікатор, який хелпдеск використовує як запасний варіант.
- Завершився термін зіставлення повідомлення. Freshdesk зазначає, що термін дії його ID повідомлення зазвичай спливає через сім днів після останньої відповіді. Після цього система шукає ID тікета або ідентифікатор тікета. Такий термін є специфічним для Freshdesk і не має вважатися типовим для інших продуктів.
Почніть діагностику з оригінального вихідного повідомлення та відповіді клієнта. Порівняйте їхні необроблені заголовки поруч, а потім перевірте власну документацію хелпдеску й часову шкалу тікета. Якщо заголовки відповіді присутні, перевірте інші вимоги платформи, як-от маркери тікета, адресу отримувача або дозволеного відправника. Якщо заголовки відсутні, простежте маршрут через постачальника електронної пошти та будь-який сервіс пересилання, щоб визначити, де саме змінилося повідомлення.
Як Deskhero зберігає історію листування цілісною
Deskhero перетворює наявну поштову скриньку Gmail, Google Workspace або Microsoft 365 на хелпдеск. Він також підтримує поштові скриньки на інших власних доменах через DNS-автентифікацію та вхідне пересилання.
- Підключення Google і Microsoft забезпечують двосторонню синхронізацію, тому Deskhero може читати вхідну пошту та надсилати відповіді від підключеної адреси.
- Поштова скринька на основі DNS використовує записи DKIM для автентифікованого надсилання та унікальну адресу Deskhero для вхідного пересилання.
- Відповіді в межах одного листування приєднуються до наявного тікета Deskhero.
- Пропоновані ШІ відповіді використовують знання робочого простору та залишаються під контролем Користувача. Автоматичні відповіді є окремою функцією, яку потрібно ввімкнути для кожної групи; вони відповідають лише на основі схвалених загальнодоступних поширених запитань.
Щоб дізнатися більше, перегляньте статті Deskhero про двосторонню синхронізацію електронної пошти хелпдеску, використання наявної поштової скриньки як хелпдеску та перетворення вхідної електронної пошти на тікет.
| Вимога | Варіант Deskhero |
|---|---|
| Підключити Gmail або Google Workspace | Підключення через OAuth із двосторонньою синхронізацією |
| Підключити Microsoft 365 або Outlook | Підключення через OAuth із двосторонньою синхронізацією, зокрема спільних поштових скриньок |
| Використовувати інший власний домен | DNS-автентифікація для надсилання та пересилання для вхідної пошти |
| Контролювати відповіді ШІ | Користувачі перевіряють запропоновані відповіді; для автоматичних відповідей потрібна окрема згода на підключення |
У чому більшість посібників із налаштування помиляється
Є спокуса звести об’єднання в ланцюжки до одного правила, наприклад збереження Message-ID. Документація постачальників показує, чому цього недостатньо. Zendesk поєднує перевірки заголовків і закодованих ID. Freshdesk поєднує кілька маркерів електронної пошти з перевіркою відправника. Amazon Connect пов’язує контакти за допомогою даних про пов’язані контакти та стандартних заголовків електронної пошти.
Кращий підхід — розглядати об’єднання в ланцюжки як наскрізну поведінку. Використовуйте підтримуване підключення поштової скриньки, не змінюйте ідентифікатори, створені продуктом, і тестуйте за допомогою реальної відповіді клієнта. Якщо результат неправильний, порівняйте необроблені повідомлення та дійте відповідно до задокументованого порядку зіставлення хелпдеску.
Це також допомагає уникнути непотрібних змін поштового сервера. Нове реле або переписаний шаблон можуть додати ще одну змінну, не усунувши справжню невідповідність.
Запустіть хелпдеск із ланцюжками, не втративши жодної відповіді
Deskhero може підключити наявну поштову скриньку Gmail, Google Workspace або Microsoft 365 через двосторонню синхронізацію. Для іншого власного домену він підтримує автентифіковане надсилання через налаштування DNS і вхідне пересилання на унікальну адресу Deskhero.
Ваші Користувачі працюють зі спільної скриньки, а відповіді надсилаються з підключеної адреси компанії. Якщо ваша служба підтримки використовує Shopify, інтеграція Shopify додає інформацію про клієнта та замовлення на бічну панель тікета.
Deskhero пропонує 30-денний безкоштовний пробний період, для якого не потрібна кредитна картка. Ви можете підключити наявну адресу замість того, щоб просити клієнтів запам’ятовувати нову.
Джерела
- Можливості електронної пошти та об’єднання в ланцюжки Amazon Connect
- Як Zendesk об’єднує вхідні листи в тікети
- Огляд каналу електронної пошти та об’єднання в ланцюжки у Freshdesk
Поширені запитання
У чому різниця між двосторонньою синхронізацією та пересиланням?
Двостороння синхронізація дає хелпдеску змогу читати з підключеної поштової скриньки та надсилати через неї повідомлення. Пересилання надсилає вхідні повідомлення до іншого місця призначення й може потребувати окремої автентифікації для вихідної пошти. Доступні методи та правила об’єднання в ланцюжки залежать від хелпдеску й постачальника електронної пошти.
Чому відповідь клієнта створила новий тікет, а не приєдналася до ланцюжка?
У відповіді можуть бути відсутні очікувані заголовки, вона може бути надіслана на іншу адресу служби підтримки, надійти від відправника, якого платформа не пов’язує з тікетом, або не містити специфічного для продукту ідентифікатора тікета. Перевірте необроблене джерело листа та задокументовані правила вашого хелпдеску.
Як перевірити, чи правильно спрацювало об’єднання в ланцюжок?
Переконайтеся, що відповідь з’явилася в наявному тікеті. Якщо ні, порівняйте значення In-Reply-To і References у відповіді з попередніми значеннями Message-ID, а потім перевірте всі ідентифікатори тікета, які використовує платформа.
Чи потрібне мені автентифіковане SMTP-реле, якщо я вже використовую двосторонню синхронізацію?
Зазвичай ні, якщо йдеться про окреме виправлення об’єднання в ланцюжки. Дотримуйтеся конфігурації надсилання, яку вимагає ваш хелпдеск. Пряме підключення поштової скриньки може вже забезпечувати вихідну пошту, тоді як налаштування на основі пересилання або DNS може використовувати інший автентифікований метод надсилання.
Чи підтримує Deskhero і Gmail, і Microsoft 365?
Так. Deskhero підтримує двосторонні підключення для Gmail, Google Workspace, Microsoft 365 та Outlook. Також підтримуються спільні поштові скриньки Microsoft.