Технологічний стек післяпродажного обслуговування: відстеження, повернення, підтримка та їхній взаємозв’язок
Технологічний стек після покупки поєднує відстеження відправлень, керування поверненнями, підтримку клієнтів і системи, у яких зберігаються записи про замовлення та платежі. Для команд електронної комерції мета полягає не в тому, щоб придбати окремий застосунок для кожного завдання. Потрібно забезпечити переміщення даних про події доставки, запити клієнтів і рішення щодо відшкодувань між системами без втрати контексту або запуску суперечливих дій.
У цьому посібнику пояснюється, за що має відповідати кожен рівень, як між ними має передаватися інформація та як тестувати з’єднання перед розширенням стеку. Найкраща відправна точка — один шлях клієнта: замовлення відправлено, щось змінюється, клієнту потрібна допомога, і хтось має вирішити, що робити далі.
Будуйте навколо відповідальності, а не списку застосунків
Інструмент відстеження може повідомляти про перебіг доставки, але оновлення відправлення не є повним записом замовлення. Портал повернень може прийняти запит, але цей запит не є підтвердженням того, що відшкодування було здійснено. Агент підтримки може схвалити виняток, але рішення все одно має надійти до системи, яка його виконує.
Ці відмінності важливі, оскільки пов’язані системи можуть відображати однакову інформацію, але не мати однакових повноважень для її зміни. Визначте авторитетну систему для кожного запису, а інші системи налаштуйте на посилання на неї.
| Рівень | Рекомендована відповідальність | Інформація для обміну |
|---|---|---|
| Комерційна платформа або система керування замовленнями | Ідентифікація замовлення, придбані товари, розподіл виконання та комерційний статус замовлення | Ідентифікатори замовлень, ідентифікатори позицій, кількість, посилання на клієнта та зв’язки з відправленнями |
| Відстеження відправлень | Видимість відправлення та інтерпретація подій доставки | Посилання на перевізника, номери відстеження, час подій, статуси та винятки |
| Керування поверненнями | Запити на повернення, перевірка політики, авторизовані товари та статус процесу повернення | Ідентифікатори повернень, кількість товарів, причини, схвалення та результати перевірки |
| Підтримка клієнтів | Розмови з клієнтами, розслідування та авторизовані винятки | Ідентифікатори звернень, відповідний контекст замовлення, рішення та відповідальні за ескалацію |
| Складські та платіжні системи | Фізичне отримання та перевірка; фінансове виконання та звірка | Результати отримання, статус товару, посилання на відшкодування та результати транзакцій |
Це рекомендована модель розподілу відповідальності, а не вимога використовувати п’ять окремих продуктів. Одна платформа може охоплювати кілька обов’язків. Перевірка полягає в тому, чи має кожен важливий стан чітко визначеного власника та чи можуть інші системи відрізнити запитану дію від завершеної.
Відстеження має пояснювати перебіг доставки, не приймаючи комерційних рішень
Рівень відстеження пов’язує активність перевізника із замовленням клієнта. Він має допомагати клієнтам розуміти, де перебуває їхня посилка, а працівникам — визначати, коли відправлення потребує уваги. Для поштових доставок відстеження поштових відправлень є частиною цього рівня видимості; ширша архітектура також має враховувати замовлення з кількома посилками або різними перевізниками.
Моделюйте замовлення та відправлення окремо. Замовлення з двома посилками може мати одну доставлену посилку, тоді як інша все ще перебуватиме в дорозі. Позначення всього замовлення як доставленого після першої події доставки може призвести до оманливих сповіщень, неправильних відповідей служби підтримки та плутанини щодо того, які товари можна повернути.
Зберігайте початкову подію разом зі спрощеним статусом
Статус для клієнта, як-от «у дорозі», легше читати, ніж стрічку подій перевізника. Командам підтримки все ще можуть бути потрібні початковий текст події, місце та мітка часу для розслідування проблеми. За можливості зберігайте обидва подання та розрізняйте момент, коли перевізник повідомив про подію, і момент, коли її отримала ваша система.
Виняток під час відстеження зазвичай має ініціювати перевірку або визначений процес, а не автоматично авторизувати відшкодування. Затримка, невдала спроба доставки та посилка, позначена як доставлена, але не отримана, потребують різних дій. Політика продавця та процес розслідування мають визначати рішення.
Визначте відповідальність за сповіщення
Вирішіть, яка система надсилає кожне повідомлення. Якщо платформа електронної комерції, застосунок відстеження та автоматизація підтримки одночасно надсилають оновлення доставки, клієнт може отримати дублікати або суперечливі повідомлення. Підтримуйте карту сповіщень із зазначенням тригера, відправника, аудиторії, умов придушення та цільового посилання.
Наприклад, повідомлення про затримку відправлення не має обіцяти заміну, якщо заміну насправді не було схвалено. Його метою може бути лише пояснення останнього статусу та надання способу звернутися по допомогу.
Для повернень потрібен контекст на рівні товару та окремий фінансовий статус
Повернення починається з товару та рішення відповідно до політики, а не лише з номера відстеження. Рівень повернень має знати, що було придбано, яка кількість товарів ще підлягає поверненню та чи впливає на запит попереднє повернення або відшкодування.
Перед впровадженням автоматизації визначте події, які просувають повернення вперед. Практичний процес може розрізняти подання запиту, схвалення запиту, передачу посилки, отримання посилки, завершення перевірки та запит на відшкодування. Фактичні етапи мають відповідати роботі вашого бізнесу.
Не зводьте ці етапи до єдиної позначки «повернено». Подія доставки від перевізника для посилки з поверненням сама по собі не підтверджує, що працівники складу перевірили її вміст. Так само запит на відшкодування не підтверджує, що платіжна система успішно обробила відшкодування.
- Для часткових повернень: обмінюйтеся ідентифікаторами позицій і кількістю, а не лише загальною сумою замовлення.
- Для обмінів: визначте, хто резервує товар, створює замовлення на заміну та обробляє будь-яку різницю в ціні.
- Для дострокових відшкодувань: визначте кваліфікаційну подію, перевірки ризиків, повноваження на схвалення та процес обробки винятків.
- Для винятків із політики: зафіксуйте, хто схвалив виняток і яку подальшу дію він дозволяє.
Використовуйте опубліковану політику та відповідні зобов’язання для визначення права на повернення. Налаштування програмного забезпечення має реалізовувати ці рішення, а не непомітно ставати самою політикою.
Підтримка є рівнем прийняття рішень щодо винятків
Робочий простір підтримки має об’єднувати достатньо контексту для вирішення справи без необхідності відновлювати історію замовлення в кількох панелях. Це не означає копіювати кожен запис у кожне звернення.
Корисна панель замовлення містить зв’язки з відправленнями, останні відповідні події відстеження, відкриті повернення, результати відшкодувань і попередні рішення. Вона також має показувати час останнього оновлення інформації. Старий статус без мітки часу може виглядати актуальним і призвести до неправильної поради агента.
Розділяйте доступ для читання та дозволи на виконання дій. Багатьом агентам може бути потрібно переглядати історію відшкодувань, але лише деякі повинні мати право оформлювати відшкодування або скасовувати право на повернення. Дії, що впливають на гроші чи запаси, мають мати журнал аудиту та захист від повторення.
Маршрутизуйте справи відповідно до необхідної роботи. Відправлення без нещодавнього руху може потребувати логістичного розслідування. Відхилена платіжна транзакція щодо відшкодування може потребувати участі платіжних операцій. Повернення з неочікуваним вмістом може потребувати перевірки складу. Категорія звернення корисна лише тоді, коли веде до визначеного відповідального та наступного кроку.
Як системи з’єднуються: відстежуйте один виняток від початку до кінця
Розглянемо умовне замовлення, що містить два товари, відправлені окремими посилками. Одна посилка прибуває, а в іншої виникає виняток доставки. Клієнт звертається до служби підтримки, а згодом повертає доставлений товар.
- Система замовлень створює зв’язки. Кожна позиція пов’язана з правильним відправленням. Підтримка бачить, що недоставлений товар не перебуває в доставленій посилці.
- Рівень відстеження отримує виняток. Він зберігає посилання на відправлення та деталі події. Процес створює або оновлює розслідування, а не вважає все замовлення втраченим.
- Підтримка перевіряє справу. Агент перевіряє відповідне відправлення та записує погоджений наступний крок. Якщо заміну авторизовано, система замовлень отримує окрему інструкцію для її створення.
- Клієнт запитує повернення доставленого товару. Система повернень перевіряє товар і кількість за замовленням та наявною активністю повернення.
- Склад отримує та перевіряє повернення. Результат перевірки додається до запису повернення, а не визначається лише за відстеженням посилки.
- Фінансовий процес виконує схвалене рішення. Результат відшкодування записується назад, щоб підтримка та клієнтське подання повернення не плутали схвалення із завершенням.
З’єднання є успішними, коли кожен учасник бачить однаковий результат, не маючи можливості перезаписувати записи поза межами своєї відповідальності.
Деталі інтеграції, які потрібно тестувати, а не приймати на віру після демонстрації продажу
Спільні ідентифікатори та зіставлення записів
Використовуйте стабільні внутрішні ідентифікатори для поєднання замовлень, позицій, відправлень, повернень і звернень. Не покладайтеся лише на адресу електронної пошти або відображуваний номер замовлення. Правила зіставлення мають враховувати інтерпретацію номерів відстеження в контексті перевізника та наявність у клієнта кількох активних замовлень.
Доставка подій і звірка
Якщо це підтримується, вебхуки можуть повідомляти приймальну систему про виникнення події. Вони не усувають потреби обробляти відсутні, затримані, повторні або отримані не по порядку повідомлення. Дізнайтеся, як повторно надсилаються невдалі доставки та як команда може відновити події після збою.
Зробіть повторну обробку безпечною. Наприклад, повторне отримання схвалення повернення не має призводити до двох відшкодувань. Завдання звірки також має порівнювати важливі записи між системами, щоб пропущене сповіщення не залишило повернення або відшкодування назавжди заблокованим.
Автентифікація та межі даних клієнта
Пошук відправлення, запит на повернення та відшкодування, оформлене агентом, потребують різних рівнів доступу. Визначте, як клієнти підтверджують право переглядати або змінювати замовлення, як призначаються дозволи працівникам і яка саме особиста інформація потрібна кожному підключеному застосунку.
Під час впровадження перевірте автентифікацію вебхуків, зберігання облікових даних, відкликання доступу, налаштування зберігання та журнали аудиту. Не копіюйте повні записи клієнтів у журнали, якщо достатньо внутрішнього посилання.
Місце 17TRACK в архітектурі
Для оцінювання, орієнтованого на 17TRACK, почніть із точки входу до продукту, яка відповідає вашому завданню. Вебсайт відстеження для споживачів призначений для пошуку окремих відправлень. Продавці, які оцінюють застосунок для відстеження замовлень, можуть переглянути сторінку 17TRACK у Shopify. Команди, які проєктують власне з’єднання, можуть ознайомитися з інформацією про Tracking API та документацією API. Вимоги до повернень слід розглядати окремо в межах оцінювання 17RETURNS.
Це відповідні шляхи оцінювання, а не доказ того, що кожне з’єднання з цього посібника доступне одразу після встановлення. Підтвердьте конкретні поля даних, підтримувані процеси, дозволи та комерційні умови для продукту, який плануєте використовувати. Не припускайте, що вибір пов’язаних продуктів автоматично синхронізує звернення до підтримки, складські перевірки або результати платежів.
Запускайте найменший процес, який усуває реальну проблему
Почніть із найдорожчої передачі роботи у вашій поточній операції. Якщо агенти постійно вручну шукають статус відправлення, пріоритетом має стати контекст відстеження в підтримці. Якщо клієнти не можуть зрозуміти, чи було повернення отримано або відшкодовано, пріоритетом має стати з’єднання між поверненням, складом і платежем.
Перш ніж купувати ще один застосунок, визначте можливості, які вже доступні у вашій комерційній платформі та системі підтримки. Додавайте спеціалізований інструмент, коли він усуває конкретну проблему, і перевіряйте весь процес, а не оцінюйте його лише за сторінкою для клієнта.
Корисний приймальний тест має містити:
- Замовлення, розділене на кілька відправлень.
- Оновлення відстеження, яке надходить після новішої події.
- Повторну подію, яка не має повторювати фінансову дію.
- Часткове повернення з попереднім відшкодуванням за тим самим замовленням.
- Невдале відшкодування, яке залишається видимим для підтримки.
- Тимчасовий збій інтеграції з подальшим відновленням.
- Ручний виняток, який змінює стандартний процес із зафіксованою причиною.
Призначте відповідального за кожен невдалий тест і визначте, як працівники працюватимуть, поки інтеграція недоступна. Ручний резервний процес є частиною дизайну, а не визнанням провалу автоматизації.
Вимірюйте результати на всіх етапах передачі
Відстежуйте кількість звернень щодо доставки на одне відправлене замовлення, час обробки повернення, невирішені помилки інтеграції та час між схваленням відшкодування і підтвердженим виконанням. Чітко визначте кожну метрику. Наприклад, розділяйте час транспортування повернення та час обробки на складі, щоб відповідальна команда могла діяти на основі результату.
За можливості порівнюйте аналогічні періоди та групи клієнтів. Зменшення кількості звернень до підтримки не обов’язково є покращенням, якщо клієнти також втратили доступ до допомоги. Поєднуйте показники ефективності з невирішеними справами, повторними зверненнями та доказами того, що клієнти отримали правильне рішення.
Часті запитання
Чи потрібні невеликим магазинам окремі інструменти для відстеження, повернень і підтримки?
Ні. Почніть із доступних можливостей і операційних проблем, які можна визначити. Окремі інструменти стають корисними, коли поточне налаштування не забезпечує достатньої видимості, контролю політики або надійної передачі роботи. Більша кількість застосунків без чіткого розподілу відповідальності може збільшити обсяг ручної роботи.
Чи мають події відстеження автоматично запускати відшкодування?
Лише в межах явно схваленого процесу з відповідними перевірками. Події відправлення описують переміщення або активність доставки; вони не обов’язково підтверджують право на відшкодування. Тримайте подію-тригер, рішення про авторизацію та фінансове виконання окремо.
Чи достатньо з’єднання через API, щоб два інструменти працювали разом?
Ні. З’єднання також потребує сумісних ідентифікаторів, зіставлення полів, дозволів, обробки помилок і правил для суперечливих оновлень. Підтвердьте, які записи можна читати або змінювати, і протестуйте бізнес-процес від початку до кінця.
Чи можна показувати повернення, позначене як доставлене, як відшкодоване?
Не лише на підставі цього доказу. Доставка на адресу повернення, отримання складом, перевірка, схвалення відшкодування та успішне виконання відшкодування є різними подіями. Повідомлення клієнтам мають указувати етап, який фактично підтверджено.
Хто має відповідати за стек після покупки?
Загальним відповідальним може бути керівник електронної комерції або операцій, тоді як команди підтримки, логістики, фінансів і технічна команда відповідають за свої відповідні процеси. Одна особа має координувати міжсистемні збої, щоб проблеми не залишалися між відділами.
Джерела
Наведені нижче офіційні ресурси продуктів і документації є відправними точками для розглянутих вище шляхів оцінювання 17TRACK. Перевіряйте вимоги, специфічні для впровадження, за відповідною документацією та умовами продукту.
