Самообслужване на клиентите в електронната търговия: проследяване на поръчки, връщания и кога да ескалирате
Самообслужването на клиентите в електронната търговия трябва да позволява на купувачите да проверяват напредъка на доставката, да разбират дали отговарят на условията за връщане и да изпълняват стандартни заявки, без да чакат служител. То трябва също да разпознава кога информацията за проследяване, правилата на политиката или автоматизацията не могат да разрешат даден проблем. За екипите по операциите и клиентското изживяване целта не е да се премахне човешката поддръжка, а да се разрешават точно стандартните заявки и изключенията да се насочват към човек, който може да предприеме действие.
Полезното изживяване след покупката отговаря на три въпроса на всяка стъпка: Какво се случва? Какво може да направи клиентът след това? Кой отговаря за проблема, ако това не помогне? Изградете проследяването на поръчки и връщанията около тези въпроси, а не около възможностите на чатбот или помощен център.
Определете какво клиентите могат безопасно да разрешат сами
Самообслужването работи най-добре, когато информацията е надеждна, следващото действие е ясно и резултатът не изисква преценка по усмотрение. Проверяването на номер за проследяване е различно от решаването дали липсваща пратка отговаря на условията за замяна. Показването на политика за връщане е различно от разрешаването на спор относно твърдяно дефектен артикул.
Използвайте следните граници като оперативен модел, а не като универсална политика. Адаптирайте ги към процеса си по изпълнение на поръчките, публикуваните условия и приложимите изисквания за защита на потребителите.
| Потребност на клиента | Подходящо действие за самообслужване | Причина за ескалиране |
|---|---|---|
| Проверка на поръчка | Показване на статуса на изпълнение и данните за пратката | Записите за поръчката си противоречат или поръчката не може да бъде открита след проверка |
| Проследяване на пратка | Показване на последното събитие от превозвача и неговия час | Очакванията за доставка не са изпълнени или статусът изисква проверка |
| Заявка за стандартно връщане | Проверка на допустимостта и обяснение на процеса за връщане | Допустимостта е оспорена или изключението изисква преценка |
| Проверка на възстановяване на сума | Показване на действителния етап на възстановяването и следващата контролна точка | Съобщената контролна точка е изтекла или записите не съвпадат |
Нека проследяването на поръчки обяснява ситуацията, а не просто да показва статус
Потвърждението на поръчка, транспортният етикет и сканирането при доставка описват различни събития. Изживяването при проследяване трябва да запазва тези различия. Самото събитие „Етикетът е създаден“ не трябва да се представя като доказателство, че превозвачът физически е получил пратката.
Показвайте референцията на поръчката, съответните артикули, идентификатора на пратката, последното събитие и часа на събитието. Разграничавайте часа на събитието от превозвача от часа, в който системата ви последно е проверила за актуализация. При разделени поръчки посочвайте кои артикули принадлежат към всяка пратка, за да не изглежда, че доставената пратка означава завършване на цялата поръчка.
Превърнете събитията за проследяване в полезни следващи стъпки
- Етикетът е създаден: Обяснете, че информацията за доставката съществува, но физическото предаване може още да не е потвърдено. Насочете пропуснатия ангажимент за изпращане към екипа по изпълнение.
- В движение: Показвайте последното отчетено движение. Ако показвате оценка за доставка, посочете, че това е оценка, а не гаранция.
- Изключение при доставката: Обяснете конкретния проблем, когато източникът го предоставя. Не превръщайте всяко изключение в обща инструкция за изчакване.
- Доставено: Показвайте отчетената информация за доставката, но предоставете отделен път за клиентите, които не могат да открият пратката.
- Няма скорошна актуализация: Посочете кога е настъпило последното събитие и какво задейства проверка. Самата липса на актуализация не е доказателство за загуба.
Избягвайте универсално правило като „свържете се с нас след три дни“ за всяка пратка. Праговете за проверка трябва да отразяват услугата за доставка, местоназначението, ангажимента за изпращане, оценката за доставка и всички съответни изисквания на превозвача за разследване. Вътрешна експресна пратка и международна икономична пратка не трябва автоматично да използват една и съща логика за ескалиране.
Третирайте „доставено, но неполучено“ като отделен проблем
Сканирането за доставка не разрешава сигнала на клиента, че пратката липсва. Предложете кратък списък за проверка: потвърдете адреса за доставка, проверете посоченото безопасно място и при необходимост попитайте членовете на домакинството или рецепцията на сградата. След това осигурете ясен път към поддръжката.
Не карайте клиентите безкрайно да повтарят този списък. Предаването към поддръжката трябва да включва идентификатора на пратката, събитието за доставка, съответните данни за доставката и вече извършените проверки. Така екипът ви може да оцени следващата стъпка според приложимата политика, вместо да третира сканирането като окончателен отговор.
Изградете връщанията около допустимостта, инструкциите и видимостта
Порталът за връщания трябва да помага на клиентите да разберат както дали могат да продължат, така и какво ще се случи след това. Формуляр, който събира заявка, но оставя всяка следваща стъпка необяснена, е само частично самообслужване.
Направете допустимостта разбираема преди подаване
Посочете приложимия срок за връщане, събитието, от което започва да тече, изискванията към състоянието на артикула, съответните изключения и наличните варианти за разрешение. Обяснете всички приложими такси или удръжки за обратна доставка, преди клиентът да потвърди. Не създавайте впечатление, че една политика за връщане важи за всеки пазар или продуктова категория.
Разграничавайте връщанията поради промяна на решението от сигналите за повредени, дефектни, неправилни или липсващи артикули. Тези ситуации може да изискват различно третиране и да включват права, различни от доброволната политика на магазина за връщане. Отказът от портала не трябва да бъде окончателното решение, когато клиентът съобщава за проблем, който изисква проверка.
Поддържайте пътя на връщането ясен
- Идентифицирайте покупката сигурно. Изискайте достатъчно информация за откриване на поръчката, без да я излагате на неупълномощени потребители.
- Изберете артикула и причината. Поддържайте заявки на ниво артикул, вместо да приемате, че се връща цялата поръчка.
- Обяснете предложеното разрешение. Разграничете възстановяване на сума, замяна и кредит в магазина, включително приложимите условия.
- Предоставете правилните инструкции. Обяснете опаковането, адреса за връщане или метода за предаване и необходимото разрешение. Кажете на клиентите да не изпращат артикула, преди да са налични приложимите инструкции.
- Показвайте напредъка след подаване. Разграничете одобрението на заявката, транспортирането на връщането, получаването в склада, проверката, когато е приложима, и обработката на възстановяването.
Не обозначавайте връщане като „възстановено“ само защото е било разрешено или получено. Одобрението, започването на възстановяването и получаването на средствата от клиента са различни събития. Ако системата ви не може да наблюдава крайния резултат на плащането, съобщете етапа, който може да потвърди, и обяснете кога поддръжката трябва да извърши проверка.
Задайте тригери за ескалиране, които посочват отговорник
Правилото за ескалиране е непълно, ако не посочва отговорния екип и следващото действие. „Свържете се с поддръжката“ е вход, а не процес за разрешаване. Вътрешно всяко изключение се нуждае от отговорник, необходимите доказателства и ангажимент за отговор, който реално можете да спазите.
- Пратката не е предадена според очакванията: Насочете случая към операциите по изпълнение или склада за проверка на изпращането, наличностите и записа за пратката.
- Пропуснат ангажимент за доставка или несъответстващо проследяване: Насочете го към отговорник по поддръжката или логистиката, който може да провери пратката и при необходимост да координира запитване към превозвача.
- Доставената пратка липсва: Насочете случая към обучен служител по поддръжката за проверка, включително приложимия процес за разследване или разрешаване.
- Връщането е отказано въпреки съобщен проблем с артикула: Насочете го към служител, обучен по политиката, вместо да повтаряте автоматичния отказ.
- Връщането е получено, но възстановяването е забавено: Насочете го според действителното затруднение, например съгласуване със склада или платежни операции.
- Подозирано компрометиране на акаунт или неправомерно използване на плащане: Насочете случая през сигурен процес за проверка, без да разкривате чувствителна информация в обикновен разговор.
Предлагайте човешки канал, когато клиентът не може да използва автоматизирания процес, дори да не е открита техническа грешка. Пречки за достъпност, липса на достъп до поръчката и необичайни обстоятелства могат да попречат на валидна заявка да се вмести в стандартен формуляр.
Предавайте контекста заедно с разговора
Полезното предаване включва потвърдената референция на поръчката, засегнатия артикул, идентификатора на пратката или връщането, последния съответен статус, резултата от политиката, избраната от клиента причина и вече предприетите действия. Включвайте само необходимата за случая информация и ограничете достъпа по подходящ начин.
Кажете на клиента какво следва: кой екип ще разгледа проблема, как ще получи отговор и какъв е очакваният срок за отговор, ако такъв е определен. Не обещавайте възстановяване, замяна или резултат от превозвача, преди отговорният екип да го е разрешил.
Избирайте инструменти според работния процес, а не според броя функции
Проверката на поръчки, проследяването чрез превозвач, връщанията и обработката на изключения са свързани, но не са взаимозаменяеми. Страницата за проследяване осигурява видимост на пратката; сама по себе си тя не установява допустимост за връщане и не разрешава компенсация. Интерфейсът за заявка за връщане все още се нуждае от надеждни правила на политиката и оперативно изпълнение.
Като практическа отправна точка страницата за проследяване на 17TRACK е свързана с видимостта на пратките в самообслужването. Екипите, които оценяват работен процес за търговци, могат да прегледат обявата на 17TRACK в Shopify, а екипите по връщанията могат да разгледат 17RETURNS. За персонализирана реализация прегледайте документацията на Tracking API, преди да определите изискванията за интеграция. Тези ресурси обхващат различни части от оценката и не трябва да се приемат като доказателство, че една конфигурация обработва всеки описан тук работен процес.
Тествайте реалната настройка спрямо магазина, услугите за доставка, политиките и процеса за поддръжка. Проверете съответствието между артикули и пратки, актуалността на статусите, проверката на клиентите, насочването на изключения, правилата за връщане и точността на състоянието на възстановяването. Потвърдете обхвата на интеграцията и търговските условия директно, вместо да приемате, че дадена продуктова категория гарантира определена възможност.
Измервайте разрешаването, а не мълчанието
По-малкият брой контакти може да означава, че клиентите са намерили отговори, но може също да означава, че не са успели да достигнат до помощ. Оценявайте самообслужването заедно с повторните контакти, неразрешените изключения, обратната връзка от клиентите и качеството на ескалациите.
- Изпълнение на задачата: Успя ли клиентът да постигне желания резултат, например да открие съответната пратка или да подаде допустимо връщане?
- Повторен контакт: Наложи ли се същият клиент отново да потърси помощ по същия проблем? Определете измервателния период и съпоставяйте случаите последователно.
- Отговорност за изключенията: Достигнаха ли ескалираните случаи до екип, който може да действа, или бяха прехвърляни многократно?
- Точност на информацията: Съответстваха ли съобщенията за проследяване, връщане и възстановяване на основните оперативни записи?
- Усилие на клиента: Налагаше ли се купувачите да въвеждат повторно информация, да обясняват отново или да преминават през недостъпен процес?
Преди стартиране тествайте разделени пратки, липсващи сканирания, просрочена доставка, частично връщане, оспорено решение за допустимост и възстановяване, което очаква проверка. Успешният тест завършва или с изпълнена задача, или с ясно и приложимо предаване към служител. Започнете с тесен и надежден процес и го разширявайте само когато изключенията му имат отговорници.
ЧЗВ
Клиентите трябва първо да се свържат с магазина или с превозвача?
Превозвачът може да обясни събитие при доставка или наличните опции за доставка. Магазинът трябва да остане достъпен контакт за покупката, проблемите по изпълнението и заявките за разрешение. Не препращайте клиентите напред-назад, когато необходимото разследване или решение принадлежи на търговеца.
Може ли чатбот да управлява цялото изживяване след покупката?
Той може да предоставя интерфейс за поддържани задачи, но все още се нуждае от точни записи, определени разрешения и маршрути за ескалиране. Не трябва да измисля дата за доставка, да предполага одобрение на възстановяване или да отменя изключение от политиката, което изисква човешка проверка.
Трябва ли всяка заявка за връщане да бъде одобрявана автоматично?
Не. Автоматичното одобрение е най-подходящо, когато заявката ясно отговаря на проверени правила и не е приложимо условие за проверка. Нееднозначната допустимост, оспореното състояние на артикула или съобщен проблем с продукта може да изискват различен работен процес. Обяснете стъпката за проверка, вместо да я представяте като необяснен отказ.
Какво трябва да показва страницата за проследяване, когато няма налична оценка?
Покажете последното потвърдено събитие, неговия час и ясно обяснение, че надеждна оценка не е налична. Включете условието за следваща проверка и канал за контакт. Честната информационна липса е по-полезна от неподкрепено обещание за доставка.
Откъде трябва да започне малък екип за електронна търговия?
Започнете с достъпна проверка на поръчки, разбираеми актуализации за пратките, ясна политика за връщане и видим канал за поддръжка. Добавяйте автоматизация към повтарящите се задачи едва след като определите отговорници за изключенията. Прост процес с надеждно изпълнение е за предпочитане пред по-голям портал, който оставя сложните случаи нерешени.
Източници
Официалните продуктови ресурси, посочени в раздела за оценка на инструментите, са изброени по-долу. Описаните по-горе граници на работния процес, моделът за ескалиране и списъкът за тестване са редакционни оперативни препоръки, а не твърдения за гарантирана функционалност на продукта.
