Технолошкиот стек по купувањето: следење, враќања, поддршка и како се поврзани
Технолошкиот стек по купувањето ги поврзува следењето на пратките, управувањето со враќања, корисничката поддршка и системите што ги чуваат записите за нарачки и плаќања. За ecommerce тимовите, целта не е да купат посебна апликација за секоја задача. Целта е настаните за испорака, барањата на клиентите и одлуките за рефундирање да се пренесуваат меѓу системите без губење на контекстот или активирање спротивставени дејства.
Овој водич објаснува што треба да опфаќа секој слој, како информациите треба да се движат меѓу нив и како да ги тестирате поврзувањата пред да го проширите стекот. Најкорисната почетна точка е едно корисничко патување: нарачката се испраќа, нешто се менува, на клиентот му е потребна помош и некој мора да одлучи што следува.
Градете околу одговорностите, а не околу списокот на апликации
Алатката за следење може да го извести напредокот на пратката, но ажурирањето на пратката не е целосен запис за нарачката. Порталот за враќања може да собере барање, но тоа барање не е доказ дека е извршено рефундирање. Агентот за поддршка може да одобри исклучок, но одлуката сепак треба да стигне до системот што ја извршува.
Овие разлики се важни затоа што поврзаните системи можат да ги прикажуваат истите информации без да имаат исто овластување да ги менуваат. Одредете авторитативен систем за секој запис и направете другите системи да се повикуваат на него.
| Слој | Препорачана одговорност | Информации за размена |
|---|---|---|
| Commerce платформа или систем за управување со нарачки | Идентитет на нарачката, купени производи, распределба на исполнувањето и комерцијален статус на нарачката | Идентификатори на нарачки, идентификатори на ставки, количини, референци за клиенти и поврзаности со пратки |
| Следење на пратки | Видливост на пратките и толкување на настаните за испорака | Референци на превозници, броеви за следење, времиња на настани, статуси и исклучоци |
| Управување со враќања | Барања за враќање, проверки на политиките, одобрени производи и статус на работниот тек за враќање | Идентификатори на враќања, количини на производи, причини, одобрувања и резултати од проверките |
| Корисничка поддршка | Разговори со клиенти, истрага и овластени исклучоци | Идентификатори на тикети, релевантен контекст на нарачката, одлуки и одговорност за ескалација |
| Системи за магацин и плаќања | Физички прием и проверка; финансиско извршување и усогласување | Резултати од приемот, одредување на статусот на производите, референци на рефундирања и резултати од трансакциите |
Ова е препорачан модел на сопственост, а не барање да користите пет одделни производи. Една платформа може да опфаќа повеќе одговорности. Тестот е дали секоја важна состојба има јасен сопственик и дали другите системи можат да разликуваат побарано дејство од завршено дејство.
Следењето треба да го објаснува напредокот на пратката без да донесува комерцијални одлуки
Слојот за следење ја поврзува активноста на превозникот со нарачката на клиентот. Треба да им помогне на клиентите да разберат каде се наоѓа нивниот пакет и да им помогне на вработените да препознаат кога на пратката ѝ е потребно внимание. За поштенски испораки, следењето поштенски пратки е еден дел од тој слој на видливост; пошироката архитектура мора да ги опфати и нарачките со повеќе пакети или различни превозници.
Моделирајте ги нарачките и пратките одделно. Нарачка со два пакети може да има еден пакет што е испорачан, а другиот сè уште да се движи. Обележувањето на целата нарачка како испорачана по првиот настан на испорака може да создаде погрешни известувања, неточни одговори од поддршката и забуна околу тоа кои производи може да се вратат.
Чувајте го оригиналниот настан заедно со поедноставениот статус
Статусот за клиентите, како „во транзит“, е полесен за читање од низата настани од превозникот. На тимовите за поддршка можеби сè уште ќе им бидат потребни оригиналниот текст на настанот, локацијата и временскиот печат за да истражат проблем. Каде што е можно, зачувајте ги двата приказа и разликувајте кога превозникот вели дека се случил настанот од моментот кога вашиот систем го примил.
Исклучокот при следење вообичаено треба да иницира преглед или дефиниран работен тек, а не автоматски да одобри рефундирање. Доцнење, обид за испорака и пакет пријавен како испорачан, но непронајден, бараат различни дејства. Политиката на трговецот и процесот на истрага треба да го одредат решението.
Доделете одговорност за известувањата
Одлучете кој систем ја испраќа секоја порака. Ако commerce платформата, апликацијата за следење и автоматизацијата за поддршка испраќаат известувања за испорака, клиентот може да добие дупликат или неконзистентни пораки. Одржувајте мапа на известувања што ги наведува активирањето, испраќачот, публиката, условите за потиснување и целниот линк.
На пример, пораката за доцнење на пратката не треба да ветува замена освен ако замената навистина не е одобрена. Нејзината цел може едноставно да биде да го објасни најновиот статус и да понуди начин за добивање помош.
Враќањата бараат контекст на ниво на производ и одделна финансиска состојба
Враќањето започнува со производ и одлука според политиката, а не само со број за следење. Слојот за враќања треба да знае што е купено, кои количини сè уште може да се вратат и дали претходно враќање или рефундирање веќе влијае врз барањето.
Пред да воведете автоматизација, дефинирајте ги настаните што го придвижуваат враќањето. Практичниот работен тек може да разликува: поднесено барање, одобрено барање, предаден пакет, примен пакет, завршена проверка и побарано рефундирање. Вашите конкретни фази треба да одговараат на начинот на кој работи бизнисот.
Не спојувајте ги овие фази во една ознака „вратено“. Настанот за испорака од превозникот за пакетот што се враќа сам по себе не потврдува дека вработените во магацинот ја провериле неговата содржина. Исто така, барањето за рефундирање не потврдува дека системот за плаќања успешно го обработил рефундирањето.
- За делумни враќања: разменувајте идентификатори и количини на ставки, а не само вкупната вредност на нарачката.
- За замени: дефинирајте кој резервира залиха, ја создава заменската нарачка и ја обработува евентуалната разлика во цената.
- За рани рефундирања: наведете го квалификувачкиот настан, проверките на ризик, овластувањето за одобрување и процесот за исклучоци.
- За исклучоци од политиката: запишете кој го одобрил исклучокот и кое последователно дејство го дозволува.
Користете ја објавената политика и применливите обврски за да ја дефинирате подобноста. Конфигурацијата на софтверот треба да ги спроведува тие одлуки, а не тивко да стане самата политика.
Поддршката е слојот за одлуки при исклучоци
Работниот простор за поддршка треба да обедини доволно контекст за решавање на случајот без агентите да мораат повторно да ја составуваат нарачката низ неколку контролни табли. Тоа не значи копирање на секој запис во секој тикет.
Корисниот панел за нарачка вклучува поврзаности со пратки, најнови релевантни настани од следењето, отворени враќања, резултати од рефундирања и претходни одлуки. Треба да прикажува и кога последен пат се ажурирани информациите. Стар статус без временски печат може да изгледа актуелно и да го наведе агентот да даде погрешен совет.
Одделете го пристапот за читање од дозволите за дејства. На многу агенти можеби ќе им треба увид во историјата на рефундирања; на помалку агенти треба да им биде дозволено да издадат рефундирање или да ја надминат подобноста за враќање. Дејствата што влијаат врз пари или залиха треба да имаат ревизорска трага и заштити од повторување.
Насочувајте ги случаите според потребната работа. Пратка без неодамнешно движење можеби бара логистичка истрага. Одбиена трансакција за рефундирање можеби бара финансиски операции. Вратена пратка со неочекувана содржина можеби бара проверка во магацин. Категоријата на тикетот е корисна само ако води до именуван сопственик и следен чекор.
Како се поврзуваат системите: следете еден исклучок од почеток до крај
Разгледајте илустративна нарачка со два производи испратени во одделни пакети. Еден пакет пристигнува; кај другиот се појавува исклучок при испораката. Клиентот контактира со поддршката и подоцна го враќа испорачаниот производ.
- Системот за нарачки ги создава поврзаностите. Секоја ставка е поврзана со точната пратка. Поддршката може да види дека неиспорачаниот производ не се наоѓа во испорачаниот пакет.
- Слојот за следење прима исклучок. Тој ја зачувува референцата на пратката и деталите за настанот. Работниот тек создава или ажурира истрага наместо целата нарачка да ја третира како изгубена.
- Поддршката го прегледува случајот. Агентот ја проверува релевантната пратка и го запишува договорениот следен чекор. Ако е одобрена замена, системот за нарачки добива посебна инструкција да ја создаде.
- Клиентот бара враќање на испорачаниот производ. Системот за враќања ги проверува производот и количината во однос на нарачката и постојната активност за враќање.
- Магацинот го прима и го проверува враќањето. Резултатот од проверката се прикачува на записот за враќање, а не се заклучува само врз основа на следењето на пакетот.
- Финансискиот работен тек го извршува одобреното решение. Резултатот од рефундирањето се запишува назад за поддршката и приказот на враќањето за клиентот да не го мешаат одобрувањето со завршувањето.
Поврзувањата се успешни кога секој учесник го гледа истиот исход без да му биде дозволено да ги презапишува записите надвор од својата одговорност.
Детали за интеграцијата што заслужуваат тест, а не претпоставка од продажна демонстрација
Споделени идентификатори и усогласување на записи
Користете стабилни интерни идентификатори за поврзување на нарачки, ставки, пратки, враќања и тикети. Не потпирајте се само на адреса на е-пошта или прикажан број на нарачка. Правилата за усогласување треба да земат предвид дека броевите за следење се толкуваат во контекст на превозникот и дека клиентот може да има неколку активни нарачки.
Испорака на настани и усогласување
Каде што е поддржано, webhook-овите можат да го известат приемниот систем кога ќе се случи настан. Тие не ја отстрануваат потребата да се обработат исчезнати, задоцнети, повторени или пораки пристигнати по погрешен редослед. Прашајте како се повторува испораката по неуспех и како вашиот тим може да ги обнови настаните по прекин.
Направете повторената обработка безбедна. На пример, приемот на истото одобрување за враќање двапати не треба да издаде две рефундирања. Работата за усогласување треба да ги споредува и важните записи меѓу системите за пропуштено известување да не остави враќање или рефундирање трајно заглавено.
Автентикација и граници на податоците за клиентите
Пребарувањето за следење, барањето за враќање и рефундирањето издадено од агент бараат различни нивоа на пристап. Одлучете како клиентите докажуваат дека можат да гледаат или менуваат нарачка, како се доделуваат дозволите на вработените и кои лични информации навистина му се потребни на секоја поврзана апликација.
Проверете ја автентикацијата на webhook-овите, складирањето на акредитивите, одземањето на пристапот, поставките за задржување и ревизорските логови при имплементацијата. Избегнувајте копирање целосни записи за клиенти во логовите кога е доволна интерна референца.
Каде се вклопува 17TRACK во архитектурата
За евалуација ориентирана кон 17TRACK, започнете со влезната точка на производот што одговара на работата. Веб-страницата за следење за потрошувачи е релевантна за индивидуално пребарување на пратки. Трговците што проценуваат апликација за следење на нарачки можат да го разгледаат 17TRACK записот во Shopify. Тимовите што дизајнираат сопствено поврзување можат да ги консултираат информациите за Tracking API и API документацијата. Барањата за враќања треба да се разгледаат одделно преку 17RETURNS.
Ова се релевантни патеки за евалуација, а не доказ дека секое поврзување во овој водич е достапно веднаш. Потврдете ги конкретните полиња на податоци, поддржаните работни текови, дозволите и комерцијалните услови за производот што планирате да го користите. Не претпоставувајте дека изборот на поврзани производи автоматски ги синхронизира тикетите за поддршка, проверките во магацин или резултатите од плаќањата.
Воведете го најмалиот работен тек што решава вистински недостаток
Започнете со најскапото предавање во вашето постојно работење. Ако агентите постојано рачно го проверуваат статусот на пратките, приоритет нека биде контекстот на следењето во поддршката. Ако клиентите не можат да видат дали враќањето е примено или рефундирано, приоритет нека биде поврзувањето враќање–магацин–плаќање.
Пред да купите друга апликација, мапирајте ги можностите што веќе се достапни во вашата commerce платформа и системот за поддршка. Додадете специјализирана алатка кога решава дефиниран недостаток и проверете го целиот работен тек наместо да го оценувате само според страницата видлива за клиентот.
Корисниот тест за прифаќање треба да вклучува:
- Нарачка поделена на повеќе пратки.
- Ажурирање на следењето што пристигнува по понов настан.
- Повторен настан што не смее повторно да активира финансиско дејство.
- Делумно враќање со претходно рефундирање на истата нарачка.
- Неуспешно рефундирање што останува видливо за поддршката.
- Привремен прекин на интеграцијата проследен со обновување.
- Рачен исклучок што го надминува нормалниот работен тек со запишана причина.
Доделете сопственик за секој неуспешен тест и дефинирајте како вработените ќе работат додека интеграцијата е недостапна. Рачниот резервен процес е дел од дизајнот, а не признание дека автоматизацијата не успеала.
Мерете ги резултатите низ предавањата
Следете ги контактите поврзани со испораката по испорачана нарачка, времето за обработка на враќањата, нерешените грешки на интеграцијата и времето меѓу одобрувањето на рефундирањето и потврденото извршување. Прецизно дефинирајте ја секоја метрика. На пример, одделете го времето на транспорт на враќањето од времето на обработка во магацинот за одговорниот тим да може да дејствува врз резултатот.
Каде што е можно, споредувајте слични периоди и групи клиенти. Намалувањето на контактите со поддршката не е автоматски подобрување ако клиентите истовремено го изгубиле пристапот до помош. Комбинирајте ги мерките за ефикасност со нерешени случаи, повторени контакти и докази дека клиентите го добиле точното решение.
ЧПП
Дали на малите продавници им се потребни одделни алатки за следење, враќања и поддршка?
Не. Започнете со можностите што веќе се достапни и оперативните проблеми што можете да ги идентификувате. Одделните алатки стануваат корисни кога тековното поставување не може да обезбеди доволна видливост, контрола на политиките или сигурни предавања. Поголем број апликации без јасна сопственост може да ја зголеми рачната работа.
Дали настаните за следење треба автоматски да активираат рефундирања?
Само во експлицитно одобрен работен тек со соодветни проверки. Настаните на пратката опишуваат движење или активност на испорака; тие не ја утврдуваат нужно подобноста за рефундирање. Одделете ги настанот што го активира дејството, одлуката за овластување и финансиското извршување.
Дали API-поврзувањето е доволно за две алатки да работат заедно?
Не. На поврзувањето му се потребни и компатибилни идентификатори, мапирање на полиња, дозволи, обработка на неуспеси и правила за спротивставени ажурирања. Потврдете кои записи можат да се читаат или менуваат и тестирајте го деловниот работен тек од почеток до крај.
Дали враќање означено како испорачано може да се прикаже како рефундирано?
Не само врз основа на тој доказ. Испораката до адреса за враќање, приемот во магацин, проверката, одобрувањето на рефундирањето и успешното извршување на рефундирањето се различни настани. Пораките до клиентите треба да ја идентификуваат фазата што навистина е потврдена.
Кој треба да биде сопственик на стекот по купувањето?
Раководителот на ecommerce или операциите е практичен целокупен сопственик, додека тимовите за поддршка, логистика, финансии и технологија се одговорни за своите работни текови. Едно лице треба да ги координира неуспесите меѓу системите за проблемите да не остануваат меѓу одделите.
Извори
Следните официјални ресурси за производи и документација се почетни точки за патеките на евалуација на 17TRACK разгледани погоре. Потврдете ги барањата специфични за имплементацијата во релевантната документација и условите на производот.
