Від електронного листа до тікета: повний посібник для команд підтримки
Що насправді означає «перетворення електронного листа на тікет»?
Перетворення електронного листа на тікет означає, що програмне забезпечення служби підтримки перетворює вхідний лист із запитом на структурований запис, який можна відстежувати. Тема й текст повідомлення стають частиною тікета, відправник — автором запиту, а вкладення залишаються разом із листуванням. Після цього команда підтримки може опрацьовувати запит у спільній черзі, а не копіювати повідомлення між поштовими скриньками.
Типовий процес перетворення електронного листа на тікет включає:
- Створення тікета: Кожне нове звернення до служби підтримки отримує ідентифікатор, статус, автора запиту та цільову чергу.
- Маршрутизація: Поштова скринька або налаштовані правила спрямовують тікет до відповідної команди.
- Відстеження листування: Відповіді залишаються прикріпленими до тікета, тому Користувачі можуть бачити всю історію в одному місці.
- Відповідальний: Тікет можна призначити Користувачеві, визначити для нього пріоритет і переміщувати між заданими статусами.
Цей процес є основою системи обліку звернень клієнтів. Він дає команді єдине місце для отримання, упорядкування, опрацювання та вимірювання запитів, що надходять електронною поштою.
Чому вашій команді підтримки потрібна система тікетів для електронної пошти
Спільна поштова скринька може працювати за невеликої кількості звернень, але зі зростанням кількості листувань керувати нею стає складніше. Повідомлення можуть залишитися непоміченими, двоє людей можуть відповісти на один і той самий запит, а команда може не знати, які питання досі залишаються відкритими.
Система тікетів для електронної пошти змінює одиницю роботи: замість повідомлення нею стає тікет. Це дає змогу використовувати корисні операційні показники:
- Час до першої відповіді: Час між створенням тікета та першою відповіддю від Користувача.
- Час вирішення: Час від першого звернення до моменту вирішення запиту.
- Кількість тікетів: Кількість тікетів, створених і вирішених протягом обраного періоду.
- Беклог: Запити, які залишаються відкритими та потребують уваги.
Надійно розрахувати ці показники за допомогою звичайної поштової скриньки складно. Система тікетів записує зміни статусу й відповіді як частину листування, завдяки чому команда отримує узгоджене джерело для звітності.
Окремі адреси, як-от billing@company.com і support@company.com, також можуть спрямовувати вхідні листи до різних команд. Точне налаштування залежить від того, як у службі підтримки сконфігуровано поштові скриньки та групи.
Поширені труднощі під час переходу від поштової скриньки до процесів із тікетами
Технічне підключення — лише частина змін. Команді також потрібні спільні правила щодо відповідальних, статусів, пріоритетів і ескалації. Без таких домовленостей черга тікетів може відтворити ту саму плутанину, що й спільна поштова скринька.
Поширені проблеми:
- Спам і автоматичні повідомлення: Повідомлення про помилки доставки, автоматичні відповіді про відсутність на робочому місці та небажана пошта можуть створювати зайвий шум, якщо платформа не фільтрує їх і не спрямовує належним чином.
- Неправильна маршрутизація: Неповні або надто загальні правила можуть спрямувати тікет не до тієї команди.
- Відсутність контексту: Система має зберігати вкладення та історію листування, щоб Користувач міг зрозуміти суть запиту.
- Невиразні теми листів: Такі теми, як «Швидке запитання», містять замало інформації для маршрутизації на основі правил.
- Старі звички: Учасники команди можуть і надалі відповідати з особистих поштових скриньок, через що листування випадає зі спільного процесу.
Практична порада: Задокументуйте, як лист перетворюється на тікет, куди спрямовується кожна адреса, коли тікет має змінювати статус і коли Користувачеві слід передати його на ескалацію. Короткою пам’яткою користуватися легше, ніж неформальним набором винятків.
Як налаштувати перетворення електронних листів на тікети у вашому програмному забезпеченні служби підтримки
Послідовність налаштування залежить від платформи, але ці кроки охоплюють найважливіші рішення:
1. Підключіть або налаштуйте пересилання з поштової скриньки підтримки. Використовуйте спеціальну адресу, як-от support@yourcompany.com. Залежно від служби підтримки, можна підключити поштову скриньку Google або Microsoft, налаштувати пересилання від іншого постачальника або скористатися адресою, наданою платформою.
2. Зіставте поштові скриньки з командами. Визначте, де мають відображатися листи, надіслані на адреси на кшталт billing@, returns@ і support@. Перед запуском протестуйте кожен маршрут реальним повідомленням.
3. Визначте, як опрацьовувати зайві повідомлення. Виявить повторювані повідомлення про помилки доставки, автоматичні відповіді та небажаних відправників. Використовуйте доступні на платформі засоби, щоб не допускати їх до активних черг.
4. Додайте невеликий набір правил маршрутизації. Почніть з умов, які легко зрозуміти й перевірити. Наприклад, поштова скринька для рахунків може безпосередньо спрямовувати тікети до команди, що відповідає за рахунки. Перевірте результат, перш ніж додавати складніші умови на основі ключових слів або ШІ.
5. Перевірте вкладення та об’єднання листування в одну гілку. Надішліть знімки екрана, PDF-файли та відповіді із зовнішнього облікового запису. Переконайтеся, що файли доступні в тікеті, а наступні відповіді додаються до наявного листування.
6. Визначте статуси та відповідальних. Узгодьте, що для вашої команди означають статуси «відкрито», «очікує», «вирішено» та «закрито». Переконайтеся, що Користувачі знають, коли призначити тікет, залишити внутрішню нотатку або звернутися по допомогу до іншої команди.
Практична порада: Першу версію зробіть простою. Запишіть кожне правило, його мету та приклад, якому воно має відповідати. Так буде значно легше діагностувати неочікувану маршрутизацію.
Як ШІ може зробити перетворення електронних листів на тікети швидшим і точнішим
ШІ може допомагати після того, як електронний лист стає тікетом, але його роль залежить від продукту. Він може класифікувати новий запит, запропонувати відповідь, перекласти листування або оцінити умову маршрутизації. Команди мають перевірити, які знання використовує ШІ та чи переглядає результат людина.
| Завдання | Підхід на основі правил | Можливий підхід із використанням ШІ |
|---|---|---|
| Маршрутизація | Зіставити поштову скриньку, відправника або ключове слово | Оцінити зміст запиту |
| Пріоритет | Застосувати визначену умову | Використати умову, оцінену ШІ, у налаштованому правилі |
| Підготовка відповіді | Почати з шаблону | Створити чернетку на основі доступних у робочому просторі знань |
| Контекст вкладення | Відкрити файл і прочитати його вручну | Включити підтримувані зображення або документи до запропонованої відповіді |
| Переклад | Використати окремий етап перекладу | Перекласти тікет і створити чернетку безпосередньо у службі підтримки |
| Контроль якості | Користувач перевіряє відповідь | Користувач переглядає, редагує або відхиляє пропозицію |
ШІ найкорисніший, коли межі його застосування чітко визначені. Запропоновану відповідь слід розглядати як чернетку, а не як доказ правильності наведеної в ній інформації. Користувач і надалі відповідає за перевірку відповіді перед її надсиланням.
Автоматизація, орієнтована на клієнтів, потребує суворіших обмежень. У Deskhero автоматичні відповіді ШІ та чат-бот відповідають лише на основі затвердженого загальнодоступного FAQ. Якщо чат-бот не може впевнено відповісти, він перенаправляє користувача до контактної форми, щоб розмову продовжила людина.
Основні висновки щодо перетворення електронних листів на тікети для команд підтримки
Добре налаштована система тікетів для електронної пошти перетворює поштову скриньку на спільний процес підтримки, результати якого можна вимірювати.
- Визначте маршрутизацію до запуску. Кожна поштова скринька має мати чітке призначення.
- Тестуйте реальні листування. Перевіряйте нові повідомлення, відповіді, вкладення та кількох одержувачів.
- Узгодьте статуси. Звітність корисна лише тоді, коли команда послідовно застосовує кожен статус.
- Додавайте автоматизацію поступово. Прості задокументовані правила легше перевіряти й підтримувати.
- Зберігайте відповідальність за людьми. Чернетки, створені ШІ, усе одно потрібно перевіряти перед надсиланням.
Рекомендації щодо впровадження та управління змінами
Почніть з однієї команди або однієї поштової скриньки. Використайте пілотний запуск, щоб перевірити маршрутизацію, дозволи, сповіщення та визначення статусів. Усуньте очевидні труднощі, перш ніж переносити решту адрес підтримки до системи.
Призначте досвідченого Користувача, який відповідатиме на запитання щодо процесу під час упровадження. Разом перегляньте невелику вибірку реальних тікетів, зокрема один тікет, який було спрямовано правильно, і один — неправильно. Це зробить правила конкретними й допоможе команді домовитися, як опрацьовувати винятки.
Документуйте зміни в міру розвитку конфігурації. Правило маршрутизації, яке мало сенс на старті, може стати непотрібним після додавання нової поштової скриньки або команди.
Ключові показники ефективності, пов’язані з перетворенням електронних листів на тікети
Кілька показників можуть продемонструвати, чи вдосконалюється процес:
Час до першої відповіді вимірює проміжок між створенням тікета та першою відповіддю. Аналізуйте не лише середнє значення, а й розподіл, оскільки невелика кількість дуже старих тікетів може залишитися непомітною за одним узагальненим показником.
Час вирішення показує, як довго тікет залишається активним. Порівнюйте схожі команди й типи запитів, а не припускайте, що кожна проблема має вирішуватися за однаковий час.
Кількість створених і вирішених тікетів показує, чи встигає команда опрацьовувати вхідний потік. Тривалий розрив може свідчити про зростання беклогу або зміну попиту.
Час за статусами допомагає відрізнити роботу, що очікує на команду, від роботи, що очікує на автора запиту. Для цього показника вкрай важливо послідовно використовувати статуси.
Безпека та конфіденційність даних у системах тікетів для електронної пошти
Електронні листи клієнтів можуть містити персональну інформацію, відомості про замовлення, дані облікових записів і вкладення. Перш ніж підключати робочу поштову скриньку, оцініть, як служба підтримки зберігає, передає та надає доступ до цієї інформації.
Перегляньте документацію щодо автентифікації, ролей користувачів, дозволів груп, зберігання, видалення, експорту та реагування на інциденти. Перевірте, хто може бачити кожну поштову скриньку і чи своєчасно втрачають доступ деактивовані облікові записи. Якщо на вашу організацію поширюються правила захисту приватності або договірні вимоги, разом із юридичною командою чи фахівцями з безпеки перевірте актуальну документацію постачальника.
Також перевірте, як автентифікується вихідна пошта і яку адресу бачитимуть клієнти. Правильна конфігурація відправника сприяє доставленню листів і допомагає легше розпізнавати справжні відповіді служби підтримки.
Правила автоматизації та процеси, що запускаються перетворенням електронного листа на тікет
Автоматизація для нових тікетів може виконати перший етап маршрутизації ще до того, як Користувач відкриє листування. Доступні тригери й дії відрізняються в різних службах підтримки, тому створюйте правила на основі задокументованих можливостей продукту.
Корисні відправні точки:
- Маршрутизація поштових скриньок: Надсилайте тікети з кожної адреси підтримки до групи, відповідальної за цю роботу.
- Правила для авторів запитів: Спрямовуйте або позначайте повідомлення з відомої адреси чи домену, якщо для цього є чітка ділова причина.
- Правила для теми або тексту: Зіставляйте конкретні терміни та встановлюйте групу, статус, пріоритет, відповідального, тег або підтримуване користувацьке поле.
- Опрацювання спаму: Видаляйте новий тікет, якщо вузька й перевірена умова визначає повторювану небажану пошту.
Автоматизації Deskhero запускаються для нових тікетів. Вони можуть оцінювати дані автора запиту, вміст повідомлення, мову або умову ШІ, а потім встановлювати підтримувані властивості тікета чи видаляти спам. Автоматичні відповіді налаштовуються окремо. Робіть правила вузькими, тестуйте їх на прикладах і перевіряйте їхній порядок, якщо відповідати можуть одразу кілька правил.
Як навчити команду підтримки працювати з процесами електронних листів і тікетів
Навчання найкраще проводити на реалістичних тікетах. Покажіть, як надходить запит, куди він спрямовується, хто за нього відповідає, який статус застосовується та що отримує клієнт.
На кожній сесії розглядайте три завдання:
- Послідовно оновлюйте статус тікета. Визначте, коли тікет є відкритим, очікує, вирішеним або закритим.
- Правильно використовуйте приватні нотатки. Фіксуйте внутрішній контекст у тікеті, не надсилаючи його автору запиту.
- Передавайте тікет на ескалацію з контекстом. Поясніть, що вже перевірено і яка допомога потрібна, перш ніж призначати тікет іншій команді.
Після запуску щотижня переглядайте кілька тікетів. Короткий і конкретний зворотний зв’язок корисніший за повторення загальної демонстрації продукту.
Deskhero перетворює наявну поштову скриньку на повноцінну службу підтримки
Deskhero підключається до Gmail, Google Workspace, Microsoft 365 і спільних поштових скриньок Microsoft. Він також може використовувати поштову скриньку на іншому власному домені через налаштування DNS і пересилання. Вхідні повідомлення стають тікетами, а відповіді можна надсилати з власної адреси компанії.
Кожна поштова скринька Deskhero спрямовується до однієї групи. Користувачі можуть керувати листуванням у спільному перегляді тікетів зі статусами, пріоритетами, призначенням, тегами, приватними нотатками, вкладеннями та зафіксованою хронологією.
Deskhero може створювати чернетки відповідей на основі знань робочого простору, зокрема опрацьованих тікетів, внутрішніх знань, затверджених загальнодоступних елементів FAQ, сторінок просканованого вебсайту, імпортованих матеріалів і даних про товари Shopify після підключення. Запропоновані відповіді можуть використовувати підтримувані вкладення із зображеннями та документами як контекст. Користувач перевіряє чернетку перед надсиланням.
Клієнтський ШІ використовує вужче джерело. Чат-бот і автоматичні відповіді ШІ відповідають лише на основі затвердженого загальнодоступного FAQ. Автоматичні дії вмикаються за бажанням, позначаються та журналюються. Deskhero також пропонує записи FAQ на основі вирішених листувань для перевірки людиною. Продукт підтримує 14 мов інтерфейсу, містить панель клієнта Shopify і надає REST API.
Почніть 30-денний безкоштовний пробний період — банківська картка не потрібна.
FAQ
Що таке система перетворення електронних листів на тікети?
Система перетворення електронних листів на тікети перетворює вхідні листи до служби підтримки на тікети з автором запиту, статусом, історією листування та іншими полями, які можна відстежувати.
Як під час перетворення електронного листа на тікет опрацьовуються вкладення?
Відповідна служба підтримки зберігає вкладення разом із листуванням у тікеті. Перед запуском перевірте типи файлів і обмеження розміру, які найчастіше отримує ваша команда.
Які правила автоматизації слід налаштувати спочатку?
Почніть із маршрутизації від поштової скриньки до команди та невеликої кількості вузьких умов для повторюваних типів запитів або небажаної пошти. Ускладнюйте правила лише після перевірки реальних результатів.
Як Deskhero обробляє перетворення електронних листів на тікети?
Deskhero підключається до поштових скриньок Google і Microsoft, зокрема до спільних поштових скриньок Microsoft. Він також підтримує поштові скриньки на інших власних доменах із налаштуванням DNS. Вхідні листування стають тікетами, а відповіді можна надсилати з власної адреси компанії.
Які показники слід відстежувати після запуску?
Почніть із кількості створених і вирішених тікетів, часу до першої відповіді, часу вирішення та часу за статусами. Використовуйте узгоджені визначення статусів, щоб результати залишалися змістовними.
Основні висновки
Система перетворення електронних листів на тікети дає командам підтримки спільну відповідальність, повний запис листування та надійну основу для звітності.
| Пункт | Деталі |
|---|---|
| Основний процес перетворення | Вхідний електронний лист стає тікетом з автором запиту, статусом, історією повідомлень і вкладеннями. |
| Важливі показники | Відстежуйте кількість створених і вирішених тікетів, час до першої відповіді, час вирішення та час за статусами. |
| Чітка відповідальність | Визначте маршрутизацію поштових скриньок, призначення, статуси та ескалацію до розширення впровадження. |
| Обережна автоматизація | Починайте з вузьких задокументованих правил і перевіряйте їхні результати, перш ніж додавати складність. |
| Налаштування Deskhero | Deskhero підключає наявні поштові скриньки, створює спільні тікети та надсилає відповіді з адреси компанії. |