Stiva tehnologică post-achiziție: urmărire, retururi, asistență și modul în care se conectează
O stivă tehnologică post-achiziție conectează urmărirea expedierilor, gestionarea retururilor, asistența pentru clienți și sistemele care păstrează înregistrările comenzilor și plăților. Pentru echipele de comerț electronic, obiectivul nu este cumpărarea unei aplicații separate pentru fiecare sarcină. Scopul este ca evenimentele de livrare, solicitările clienților și deciziile privind rambursările să circule între sisteme fără pierderea contextului sau declanșarea unor acțiuni contradictorii.
Acest ghid explică ce responsabilități ar trebui să aibă fiecare nivel, cum ar trebui să circule informațiile între ele și cum să testați conexiunile înainte de extinderea stivei. Cel mai util punct de pornire este o singură călătorie a clientului: o comandă este expediată, ceva se schimbă, clientul are nevoie de ajutor și cineva trebuie să decidă ce urmează.
Construiți în jurul responsabilităților, nu al unei liste de aplicații
Un instrument de urmărire poate raporta progresul expedierii, dar o actualizare a expedierii nu este o înregistrare completă a comenzii. Un portal de retururi poate colecta o solicitare, dar solicitarea respectivă nu dovedește că a fost emisă o rambursare. Un agent de asistență poate aproba o excepție, însă decizia trebuie să ajungă în continuare la sistemul care o execută.
Aceste distincții sunt importante deoarece sistemele conectate pot afișa aceleași informații fără a avea aceeași autoritate de a le modifica. Desemnați un sistem de referință pentru fiecare înregistrare și faceți ca celelalte sisteme să se raporteze la acesta.
| Strat | Responsabilitate recomandată | Informații de schimbat |
|---|---|---|
| Platformă de comerț sau sistem de gestionare a comenzilor | Identitatea comenzii, produsele achiziționate, alocările pentru onorare și starea comercială a comenzii | ID-uri de comandă, ID-uri ale articolelor, cantități, referințe ale clienților și asocieri cu expedierile |
| Urmărirea expedierilor | Vizibilitatea expedierii și interpretarea evenimentelor de livrare | Referințe ale transportatorului, numere de urmărire, orele evenimentelor, stări și excepții |
| Gestionarea retururilor | Solicitări de retur, verificări ale politicii, articole autorizate și starea fluxului de retur | ID-uri de retur, cantități, motive, aprobări și rezultate ale inspecției |
| Asistență pentru clienți | Conversații cu clienții, investigații și excepții autorizate | ID-uri de tichete, context relevant al comenzii, decizii și responsabilitatea pentru escaladare |
| Sisteme de depozit și plată | Recepția și inspecția fizică; executarea și reconcilierea financiară | Rezultatele recepției, destinația articolelor, referințe ale rambursărilor și rezultatele tranzacțiilor |
Acesta este un model recomandat de responsabilități, nu o cerință de a utiliza cinci produse separate. O singură platformă poate acoperi mai multe responsabilități. Testul este dacă fiecare stare importantă are un proprietar clar și dacă celelalte sisteme pot distinge între o acțiune solicitată și una finalizată.
Urmărirea ar trebui să explice progresul expedierii fără a lua decizii comerciale
Nivelul de urmărire conectează activitatea transportatorului la comanda clientului. Acesta ar trebui să îi ajute pe clienți să înțeleagă unde se află coletul și să îi ajute pe angajați să recunoască momentul în care o expediere necesită atenție. Pentru livrările poștale, urmărirea poștală reprezintă o parte a acestui nivel de vizibilitate; arhitectura mai largă trebuie să țină cont și de comenzile cu mai multe colete sau transportatori diferiți.
Modelați comenzile și expedierile separat. O comandă cu două colete poate avea un colet livrat, iar celălalt încă în tranzit. Marcarea întregii comenzi ca fiind livrată după primul eveniment de livrare poate genera notificări înșelătoare, răspunsuri incorecte din partea asistenței și confuzie privind articolele eligibile pentru retur.
Păstrați evenimentul original alături de starea simplificată
O stare destinată clientului, precum „în tranzit”, este mai ușor de citit decât fluxul de evenimente al transportatorului. Echipele de asistență pot avea totuși nevoie de textul original al evenimentului, locație și marcaj temporal pentru a investiga o problemă. Păstrați ambele vizualizări atunci când este posibil și diferențiați momentul în care transportatorul spune că a avut loc un eveniment de momentul în care sistemul dumneavoastră l-a primit.
O excepție de urmărire ar trebui, în mod normal, să inițieze o analiză sau un flux de lucru definit, nu să autorizeze automat o rambursare. O întârziere, o tentativă de livrare și un colet raportat ca livrat, dar care nu a fost primit, necesită acțiuni diferite. Politica comerciantului și procesul de investigare ar trebui să determine soluționarea.
Stabiliți responsabilitatea pentru notificări
Decideți ce sistem trimite fiecare mesaj. Dacă platforma de comerț, aplicația de urmărire și automatizarea asistenței trimit toate actualizări privind livrarea, un client poate primi mesaje duplicate sau contradictorii. Mențineți o hartă a notificărilor care specifică declanșatorul, expeditorul, publicul, condițiile de suprimare și linkul de destinație.
De exemplu, un mesaj privind întârzierea expedierii nu ar trebui să promită un înlocuitor decât dacă acesta a fost aprobat efectiv. Scopul său poate fi pur și simplu să explice cea mai recentă stare și să ofere o cale către asistență.
Retururile necesită context la nivel de articol și o stare financiară separată
Un retur începe cu un articol și o decizie de politică, nu doar cu un număr de urmărire. Nivelul de retururi trebuie să știe ce a fost achiziționat, ce cantități mai pot fi returnate și dacă un retur sau o rambursare anterioară afectează deja solicitarea.
Înainte de implementarea automatizării, definiți evenimentele care fac un retur să avanseze. Un flux practic poate distinge între solicitare trimisă, solicitare aprobată, colet predat, colet primit, inspecție finalizată și rambursare solicitată. Etapele efective ar trebui să corespundă modului în care funcționează compania.
Nu comprimați aceste etape într-o singură etichetă „returnat”. Un eveniment de livrare al transportatorului pentru un colet returnat nu stabilește de unul singur că personalul depozitului i-a inspectat conținutul. În mod similar, o solicitare de rambursare nu stabilește că sistemul de plată a procesat cu succes rambursarea.
- Pentru retururi parțiale: schimbați identificatorii și cantitățile articolelor, nu doar totalul comenzii.
- Pentru schimburi: definiți cine rezervă stocul, creează comanda de înlocuire și gestionează orice diferență de preț.
- Pentru rambursări anticipate: specificați evenimentul eligibil, verificările de risc, autoritatea de aprobare și procesul pentru excepții.
- Pentru excepții de politică: înregistrați cine a aprobat excepția și ce acțiune ulterioară permite aceasta.
Utilizați politica publicată și obligațiile aplicabile pentru a defini eligibilitatea. Configurarea software-ului ar trebui să implementeze aceste decizii, nu să devină în mod discret politica însăși.
Asistența este nivelul decizional pentru excepții
Spațiul de lucru al asistenței ar trebui să reunească suficient context pentru soluționarea unui caz fără ca agenții să fie nevoiți să reconstruiască comanda în mai multe tablouri de bord. Aceasta nu înseamnă copierea fiecărei înregistrări în fiecare tichet.
Un panou util al comenzii include asocieri cu expedierile, cele mai recente evenimente relevante de urmărire, retururi deschise, rezultate ale rambursărilor și decizii anterioare. Ar trebui să arate și când au fost actualizate ultima dată informațiile. O stare veche afișată fără marcaj temporal poate părea actuală și poate determina un agent să ofere un sfat greșit.
Separați accesul de citire de permisiunile de acțiune. Mulți agenți pot avea nevoie să vizualizeze istoricul rambursărilor; mai puțini pot avea autoritatea de a emite o rambursare sau de a anula eligibilitatea pentru retur. Acțiunile care afectează banii sau inventarul ar trebui să aibă o pistă de audit și măsuri de protecție împotriva repetării.
Direcționați cazurile în funcție de activitatea necesară. O expediere fără mișcare recentă poate necesita o investigație logistică. O tranzacție de rambursare respinsă poate necesita operațiuni de plată. Un retur primit cu un conținut neașteptat poate necesita verificarea depozitului. O categorie de tichet este utilă doar dacă duce la un responsabil nominalizat și la un pas următor.
Cum se conectează sistemele: urmăriți o singură excepție de la început până la sfârșit
Luați în considerare o comandă ilustrativă care conține două articole expediate în colete separate. Un colet ajunge, iar celălalt dezvoltă o excepție de livrare. Clientul contactează asistența și returnează ulterior articolul livrat.
- Sistemul de comenzi creează relațiile. Fiecare articol este asociat expedierii corecte. Asistența poate vedea că articolul nelivrat nu se află în coletul livrat.
- Nivelul de urmărire primește o excepție. Acesta păstrează referința expedierii și detaliile evenimentului. Un flux de lucru creează sau actualizează o investigație, în loc să trateze întreaga comandă ca fiind pierdută.
- Asistența analizează cazul. Agentul verifică expedierea relevantă și înregistrează pasul următor convenit. Dacă este autorizată o înlocuire, sistemul de comenzi primește o instrucțiune distinctă pentru crearea acesteia.
- Clientul solicită returul articolului livrat. Sistemul de retururi verifică articolul și cantitatea în raport cu comanda și activitatea de retur existentă.
- Depozitul primește și inspectează returul. Rezultatul inspecției este atașat înregistrării returului și nu este dedus exclusiv din urmărirea coletului.
- Fluxul financiar execută soluția aprobată. Rezultatul rambursării este transmis înapoi, astfel încât asistența și vizualizarea returului destinată clientului să nu confunde aprobarea cu finalizarea.
Conexiunile sunt reușite atunci când fiecare participant vede același rezultat fără a putea suprascrie înregistrări din afara responsabilității sale.
Detalii de integrare care merită testate, nu presupuse pe baza unei demonstrații de vânzări
Identificatori comuni și potrivirea înregistrărilor
Utilizați identificatori interni stabili pentru a conecta comenzile, articolele, expedierile, retururile și tichetele. Nu vă bazați doar pe o adresă de e-mail sau pe un număr de comandă afișat. Regulile de potrivire ar trebui să țină cont de interpretarea numerelor de urmărire în contextul transportatorului și de faptul că un client poate avea mai multe comenzi active.
Livrarea evenimentelor și reconcilierea
Atunci când sunt acceptate, webhook-urile pot notifica un sistem receptor când are loc un eveniment. Ele nu elimină necesitatea gestionării mesajelor lipsă, întârziate, repetate sau livrate în ordine greșită. Întrebați cum sunt reîncercate livrările eșuate și cum poate echipa dumneavoastră să recupereze evenimentele după o întrerupere.
Faceți procesarea repetată sigură. De exemplu, primirea de două ori a aceleiași aprobări de retur nu ar trebui să emită două rambursări. O sarcină de reconciliere ar trebui, de asemenea, să compare înregistrările importante între sisteme, astfel încât o notificare omisă să nu lase permanent blocat un retur sau o rambursare.
Autentificarea și limitele datelor despre clienți
O căutare de urmărire, o solicitare de retur și o rambursare emisă de un agent necesită niveluri diferite de acces. Decideți cum dovedesc clienții că pot vizualiza sau modifica o comandă, cum sunt atribuite permisiunile personalului și de ce informații personale are nevoie efectiv fiecare aplicație conectată.
Verificați autentificarea webhook-urilor, stocarea acreditărilor, revocarea accesului, setările de păstrare și jurnalele de audit în timpul implementării. Evitați copierea în jurnale a înregistrărilor complete ale clienților atunci când este suficientă o referință internă.
Unde se încadrează 17TRACK în arhitectură
Pentru o evaluare orientată spre 17TRACK, începeți cu punctul de acces al produsului care corespunde activității. Site-ul de urmărire pentru consumatori este relevant pentru căutarea individuală a expedierilor. Comercianții care evaluează o aplicație de urmărire a comenzilor pot consulta listarea 17TRACK din Shopify. Echipele care proiectează o conexiune personalizată pot consulta informațiile despre Tracking API și documentația API. Cerințele pentru retururi trebuie analizate separat în cazul 17RETURNS.
Acestea sunt căi relevante de evaluare, nu dovezi că fiecare conexiune din acest ghid este disponibilă imediat. Confirmați câmpurile de date, fluxurile de lucru acceptate, permisiunile și condițiile comerciale specifice produsului pe care intenționați să îl utilizați. Nu presupuneți că selectarea unor produse asociate sincronizează automat tichetele de asistență, inspecțiile din depozit sau rezultatele plăților.
Lansați cel mai mic flux de lucru care elimină o problemă reală
Începeți cu cea mai costisitoare predare din operațiunea existentă. Dacă agenții caută în mod repetat manual starea expedierii, acordați prioritate contextului de urmărire în asistență. Dacă clienții nu pot afla dacă un retur a fost primit sau rambursat, acordați prioritate conexiunii dintre retur, depozit și plată.
Înainte de a cumpăra o altă aplicație, mapați capabilitățile deja disponibile în platforma de comerț și în sistemul de asistență. Adăugați un instrument specializat atunci când rezolvă o lacună definită și verificați întregul flux de lucru, nu doar pagina destinată clientului.
Un test util de acceptare ar trebui să includă:
- O comandă împărțită în mai multe expedieri.
- O actualizare de urmărire care sosește după un eveniment mai nou.
- Un eveniment repetat care nu trebuie să repete o acțiune financiară.
- Un retur parțial cu o rambursare anterioară pentru aceeași comandă.
- O rambursare eșuată care rămâne vizibilă pentru asistență.
- O întrerupere temporară a integrării urmată de recuperare.
- O excepție manuală care suprascrie fluxul normal, cu un motiv înregistrat.
Atribuiți un responsabil fiecărui test eșuat și definiți modul în care personalul va lucra când integrarea nu este disponibilă. O alternativă manuală face parte din proiectare, nu este o recunoaștere a faptului că automatizarea a eșuat.
Măsurați rezultatele de-a lungul predărilor
Urmăriți contactele referitoare la livrare per comandă expediată, timpul de procesare a retururilor, erorile de integrare nerezolvate și timpul dintre aprobarea rambursării și confirmarea executării. Definiți cu precizie fiecare indicator. De exemplu, separați timpul de transport al returului de timpul de procesare în depozit, astfel încât echipa responsabilă să poată acționa pe baza rezultatului.
Comparați perioade similare și grupuri de clienți atunci când este posibil. O scădere a contactelor cu asistența nu reprezintă automat o îmbunătățire dacă și accesul clienților la ajutor a fost redus. Asociați măsurile de eficiență cu cazurile nerezolvate, contactele repetate și dovezile că clienții au primit soluția corectă.
Întrebări frecvente
Au magazinele mici nevoie de instrumente separate pentru urmărire, retururi și asistență?
Nu. Începeți cu capabilitățile deja disponibile și cu problemele operaționale pe care le puteți identifica. Instrumentele separate devin utile atunci când configurația actuală nu poate oferi suficientă vizibilitate, control asupra politicilor sau predări fiabile. Mai multe aplicații fără o responsabilitate clară pot crește volumul de muncă manuală.
Ar trebui ca evenimentele de urmărire să declanșeze automat rambursări?
Doar în cadrul unui flux de lucru aprobat explicit și cu verificări adecvate. Evenimentele expedierii descriu mișcarea sau activitatea de livrare; ele nu stabilesc neapărat eligibilitatea pentru rambursare. Păstrați separat evenimentul declanșator, decizia de autorizare și executarea financiară.
Este suficientă o conexiune API pentru ca două instrumente să funcționeze împreună?
Nu. Conexiunea are nevoie și de identificatori compatibili, maparea câmpurilor, permisiuni, gestionarea erorilor și reguli pentru actualizările contradictorii. Confirmați ce înregistrări pot fi citite sau modificate și testați fluxul de lucru de la început până la sfârșit.
Poate un retur marcat ca livrat să fie afișat ca rambursat?
Nu doar pe baza acestei dovezi. Livrarea la adresa de retur, recepția în depozit, inspecția, aprobarea rambursării și executarea cu succes a rambursării sunt evenimente diferite. Mesajele către clienți ar trebui să identifice etapa care a fost confirmată efectiv.
Cine ar trebui să fie responsabil de stiva post-achiziție?
Un lider de comerț electronic sau de operațiuni este un responsabil general practic, iar echipele de asistență, logistică, financiară și tehnică sunt responsabile pentru fluxurile lor respective. O persoană ar trebui să coordoneze defecțiunile între sisteme, astfel încât problemele să nu rămână între departamente.
Surse
Următoarele resurse oficiale despre produse și documentație reprezintă punctele de pornire pentru căile de evaluare 17TRACK discutate mai sus. Verificați cerințele specifice implementării în documentația relevantă și în termenii produsului.
