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