Skip to main content
AcasăBlogResurseCum să automatizezi notificările privind expedierea: declanșatoare, canale și șabloane în 6 pași

Cum să automatizezi notificările privind expedierea: declanșatoare, canale și șabloane în 6 pași

17TRACK

Pentru a automatiza notificările de expediere, conectați evenimentele de expediere la înregistrările comenzilor, definiți ce modificări de stare merită un mesaj, alegeți un canal de livrare permis și atașați un șablon fiecărui declanșator. Apoi adăugați prevenirea duplicatelor, gestionarea excepțiilor și testarea înainte de lansare. Cei șase pași de mai jos arată echipelor de comerț electronic cum să creeze un flux de lucru care oferă clienților actualizări utile fără a trimite alerte repetitive sau înșelătoare.

Cum să automatizați declanșatoarele, canalele și șabloanele notificărilor de expediere în 6 pași

Acest ghid este destinat comercianților, echipelor de operațiuni pentru comerț electronic și dezvoltatorilor responsabili de comunicarea post-achiziție. Punctul de pornire recomandat este un set restrâns de notificări fiabile: acceptarea de către transportator, expedierea pentru livrare, livrarea și excepțiile care necesită acțiunea clientului. Adăugați alte mesaje numai atunci când răspund unei întrebări distincte a clientului.

1. Conectați evenimentele de urmărire la comanda și destinatarul corecte

O etichetă de expediere, o scanare a transportatorului și o notificare pentru client sunt lucruri diferite. Crearea unei etichete nu confirmă faptul că transportatorul a primit coletul. Automatizarea trebuie să păstreze această distincție încă de la început.

Începeți prin identificarea sistemului care va lua deciziile privind notificările. Acesta poate fi fluxul de notificări al magazinului, o aplicație de urmărire sau un serviciu conectat la sistemul de gestionare a comenzilor. Atribuiți un singur responsabil pentru fiecare tip de mesaj, astfel încât mai multe sisteme să nu trimită independent aceeași actualizare.

Două metode practice de implementare sunt:

  • Configurare bazată pe aplicație: Folosiți o aplicație de urmărire pentru comerț electronic atunci când echipa dorește să configureze evenimentele acceptate și mesajele adresate clienților fără a construi întreaga integrare. Pentru comercianții Shopify, listarea aplicației 17TRACK este un punct de pornire relevant pentru evaluarea fluxurilor de urmărire a expedierilor și de notificare. Confirmați declanșatoarele, canalele, opțiunile de personalizare și cerințele planului înainte de configurarea regulilor.
  • Configurare bazată pe API: Folosiți o integrare de urmărire atunci când evenimentele de expediere trebuie să alimenteze un sistem de comenzi existent sau un flux personalizat de mesagerie. API-ul de urmărire 17TRACK și documentația oficială reprezintă referințe relevante pentru implementare. Confirmați mecanismul de livrare a evenimentelor, câmpurile sarcinii utile, autentificarea și comportamentul la reîncercare pentru integrarea pe care intenționați să o utilizați. Primirea datelor de urmărire și trimiterea mesajelor către clienți sunt responsabilități separate.

Indiferent de metoda aleasă, asociați fiecare expediere cu comanda și destinatarul corecte. O înregistrare internă utilă conține:

  • Referința comenzii și identificatorul expedierii.
  • Numărul de urmărire și identificatorul transportatorului, dacă sunt disponibile.
  • Articolele incluse în expedierea respectivă, în special pentru comenzile împărțite.
  • Datele de contact ale clientului, limba, fusul orar și preferințele privind canalele.
  • Ultima stare acceptată a expedierii și ora producerii evenimentului.
  • Istoricul notificărilor, inclusiv expedierea la care s-a referit fiecare mesaj.

Păstrați separat ora producerii evenimentului și ora la care sistemul a primit actualizarea. O scanare întârziată nu ar trebui să devină automat o alertă nouă pentru client. De asemenea, păstrați descrierea originală a transportatorului alături de starea normalizată, pentru ca echipa de asistență să poată investiga evenimentele ambigue.

2. Definiți declanșatoare care reflectă modificări semnificative ale expedierii

Un declanșator ar trebui să reprezinte o modificare relevantă pentru client, nu fiecare înregistrare nouă de urmărire. Mai multe scanări efectuate în centre pot însemna toate „în tranzit”. Trimiterea unei notificări pentru fiecare dintre ele creează zgomot fără a ajuta clientul să ia o decizie.

Asociați evenimentele primite cu un set restrâns de stări ușor de înțeles. Tabelul următor reprezintă un flux de lucru sugerat, nu un dicționar universal al stărilor transportatorilor.

DeclanșatorCondiția de trimitereScopul mesajului
Etichetă creatăOpțional; diferențiați pregătirea de preluarea de către transportator.Explicați că detaliile de urmărire sunt disponibile.
Acceptarea de către transportatorUn eveniment acceptat indică faptul că transportatorul a primit coletul.Confirmați că expedierea a intrat în rețeaua transportatorului.
În tranzitReper opțional; suprimați scanările de rutină repetate.Oferiți un progres semnificativ, nu un flux scanare cu scanare.
Expediat pentru livrareStarea primită susține explicit această interpretare.Ajutați clientul să se pregătească pentru primirea coletului.
Excepție de livrareA fost identificată o problemă semnificativă sau o acțiune necesară.Explicați problema și următorul pas util.
LivratTransportatorul raportează livrarea acestei expedieri.Confirmați rezultatul raportat și oferiți o modalitate de a primi ajutor.

Gestionați excepțiile cu mai multă atenție decât reperele de rutină. O încercare eșuată de livrare, o problemă vamală, o problemă de adresă și un eveniment de returnare către expeditor pot necesita instrucțiuni diferite. Dacă evenimentul nu explică ce ar trebui să facă clientul, nu inventați o soluție.

Pentru o regulă de tipul „nicio actualizare recentă”, alegeți un prag adecvat serviciului și rutei, în loc să aplicați un singur interval universal. Lipsa scanărilor nu dovedește că un colet s-a pierdut. Direcționați cazurile incerte către o coadă internă de verificare sau trimiteți o actualizare neutră care descrie cu exactitate ceea ce se cunoaște.

Păstrați datele estimate de livrare separate de stările expedierii. Includeți o estimare numai atunci când aveți o sursă fiabilă, identificați-o drept estimare și evitați să înlocuiți datele lipsă cu o promisiune calculată pe care operațiunea nu o poate susține.

3. Alegeți canalele și stabiliți regulile de contact

Folosiți un canal deoarece se potrivește mesajului și preferințelor clientului, nu pur și simplu pentru că este disponibil. E-mailul este un punct de pornire practic pentru actualizări detaliate. Un canal mai imediat poate fi util pentru o acțiune urgentă, dar numai atunci când permisiunea, regulile furnizorului și cerințele locale permit acest lucru.

  • E-mail: Potrivit pentru contextul comenzii, linkurile de urmărire, explicațiile privind expedierile împărțite și instrucțiunile de asistență. Includeți o versiune text simplu și verificați aspectul pe mobil.
  • SMS: Util pentru alerte scurte și orientate spre acțiune, acolo unde este permis. Identificați expeditorul, păstrați mesajul concis și evitați expunerea informațiilor inutile despre comandă.
  • Notificări push: Potrivite atunci când clienții folosesc aplicația dumneavoastră și au activat notificările. Creați un link către expedierea relevantă, nu către un ecran generic de pornire.
  • Aplicații de mesagerie: Luați-le în considerare atunci când clienții folosesc deja canalul, iar implementarea respectă cerințele platformei privind permisiunile și mesajele.
  • Pagina de urmărire: Folosiți-o ca destinație de referință detaliată. Completează notificările trimise, dar nu înlocuiește o alertă atunci când clientul trebuie să acționeze.

Documentați relația dintre canale. De exemplu, puteți folosi e-mailul pentru reperele de rutină și un canal mobil permis pentru o problemă de livrare care necesită acțiune. Nu trimiteți automat fiecare eveniment prin toate canalele disponibile.

Stabiliți gestionarea orelor de liniște și o politică de rezervă. O eroare temporară de e-mail nu ar trebui să autorizeze automat un SMS. Înainte de a schimba canalul, verificați dacă aveți datele de contact și permisiunea corespunzătoare și dacă un alt sistem nu a trimis deja mesajul.

Păstrați actualizările expedierilor operaționale. Adăugarea de conținut promoțional poate afecta modul în care este tratat un mesaj conform normelor aplicabile. În Statele Unite, îndrumările FTC privind CAN-SPAM explică faptul că scopul principal al unui mesaj este important atunci când conținutul comercial și cel tranzacțional sunt combinate. Nu presupuneți că orice mesaj care menționează o comandă este exceptat de la cerințele privind e-mailurile comerciale.

4. Creați șabloane cu un comportament clar de rezervă

Fiecare șablon ar trebui să răspundă la trei întrebări: Ce s-a întâmplat? Ce înseamnă acest lucru pentru expedierea respectivă? Ce ar trebui să facă clientul în continuare? Folosiți câmpuri condiționale astfel încât datele lipsă să dispară fără probleme, în loc să lase substituenți nefuncționali.

Exemplele de mai jos sunt șabloane de pornire. Variabilele dintre paranteze sunt ilustrative și nu reprezintă sintaxa de șablon a unei platforme specifice.

E-mail privind acceptarea de către transportator

Subiect: Expedierea dumneavoastră pentru comanda [order_number] este pe drum

Bună, [first_name],

[carrier_name] a primit expedierea dumneavoastră pentru comanda [order_number]. Puteți urmări progresul aici: [tracking_link].

[Dacă este disponibilă o estimare fiabilă: Livrare estimată: [estimated_delivery_date]. Această estimare se poate modifica.]

[Dacă comanda este împărțită: Această expediere conține [shipment_items]. Celelalte articole din comanda dumneavoastră vor avea actualizări de urmărire separate.]

Mesaj privind expedierea pentru livrare

Conform celei mai recente actualizări a transportatorului, expedierea dumneavoastră pentru comanda [order_number] este în curs de livrare. Verificați progresul și detaliile de livrare disponibile: [tracking_link].

Nu adăugați o oră garantată de sosire decât dacă operațiunea dumneavoastră are o bază solidă pentru această promisiune. „Expediat pentru livrare” este o stare raportată, nu o garanție că livrarea va fi finalizată în acea zi.

Mesaj privind o excepție cu un pas următor verificat

Subiect: O actualizare privind livrarea comenzii [order_number]

Transportatorul a raportat [plain_language_issue] pentru expedierea dumneavoastră. [verified_next_step]. Consultați cele mai recente detalii aici: [tracking_link]. Dacă aveți nevoie de ajutor, contactați-ne la [support_link].

Dacă nu este confirmat niciun pas următor, înlocuiți propoziția respectivă cu: „Nu avem încă un pas următor confirmat. Verificați pagina de urmărire pentru actualizări sau contactați echipa noastră de asistență.” Spuneți că echipa dumneavoastră investighează situația numai dacă a fost într-adevăr atribuită o verificare.

E-mail privind livrarea

Subiect: Expedierea dumneavoastră a fost marcată ca livrată

[carrier_name] a marcat expedierea dumneavoastră pentru comanda [order_number] ca fiind livrată la [delivery_date]. Consultați aici detaliile de livrare disponibile: [tracking_link]. Dacă nu o puteți găsi, contactați-ne la [support_link] pentru a vă ajuta să verificați pașii următori.

Folosiți formulări la nivel de expediere pentru comenzile împărțite. „Comanda dumneavoastră a sosit” poate induce în eroare atunci când un alt colet este încă în tranzit. Dacă numele transportatorului, data sau numele clientului nu sunt disponibile, folosiți o propoziție alternativă testată în loc să afișați un câmp gol.

5. Adăugați măsuri de protecție împotriva mesajelor duplicate, vechi și înșelătoare

Automatizarea are nevoie de o evidență a acțiunilor deja efectuate. Un flux de lucru care trimite pur și simplu un mesaj de fiecare dată când sosește un eveniment poate repeta alertele după reîncercări sau poate furniza informații depășite după un reper mai nou.

  • Preveniți procesarea duplicată: Folosiți un identificator stabil al evenimentului, dacă este disponibil. În caz contrar, definiți o cheie de deduplicare din câmpuri potrivite, precum expedierea, tipul evenimentului și ora producerii evenimentului. Înregistrați separat dacă notificarea corespunzătoare a fost deja programată sau trimisă.
  • Suprimați repetarea stării: Mai multe scanări asociate aceleiași stări vizibile pentru client nu ar trebui să producă automat mai multe mesaje.
  • Verificați relevanța evenimentului înainte de trimitere: Reevaluați mesajele din coadă înainte de a le trimite. Suprimați o alertă veche privind tranzitul dacă livrarea a fost raportată între timp.
  • Gestionați corecțiile în mod deliberat: Păstrați istoricul original al evenimentelor și examinați regresiile aparente. Nu presupuneți că orice eveniment sosit ulterior este mai nou sau mai precis.
  • Reîncercați în siguranță: Diferențiați o trimitere eșuată de un rezultat necunoscut. Atunci când este acceptat, folosiți funcțiile de idempotență ale furnizorului pentru a reduce probabilitatea ca o reîncercare să creeze un alt mesaj.
  • Protejați asocierea destinatarului: Nu asociați niciodată o expediere cu un client bazându-vă doar pe o potrivire neverificată a numărului de urmărire.
  • Escaladați excepțiile nerezolvate: Atribuiți un responsabil operațional în loc să trimiteți clientului aceeași avertizare în mod repetat.

Pentru integrările personalizate, urmați abordarea documentată de furnizor privind autentificarea, confirmarea evenimentelor și reîncercările. Păstrați jurnalele de procesare utile fără a copia în acestea date personale inutile. Linkurile de urmărire ar trebui, de asemenea, să evite expunerea comenzilor altor clienți sau a unor informații care depășesc ceea ce are nevoie destinatarul.

O secvență utilă de procesare este: validați evenimentul, identificați expedierea, actualizați starea acesteia, verificați eligibilitatea notificării, selectați un canal permis, generați șablonul, puneți mesajul în coadă și înregistrați rezultatul. Verificați din nou eligibilitatea la trimitere dacă mesajul așteaptă într-o coadă.

6. Testați parcursul complet, apoi lansați treptat

Nu evaluați fluxul de lucru doar în funcție de aspectul corect al unui e-mail de test. Testați întregul traseu, de la evenimentul expedierii până la destinația clientului, inclusiv cazurile de eroare.

  • Parcurs normal: Acceptarea, tranzitul, expedierea pentru livrare și livrarea produc mesajele dorite.
  • Eveniment repetat: Redarea aceluiași eveniment nu creează o altă notificare.
  • Eveniment în ordine greșită: O scanare întârziată în tranzit nu declanșează o alertă depășită după livrare.
  • Comandă împărțită: Fiecare mesaj identifică expedierea corectă și nu sugerează că au sosit toate articolele.
  • Câmpuri lipsă: Lipsa numelui, a transportatorului, a estimării sau a listei de articole produce un text de rezervă lizibil.
  • Restricții de contact: Fluxul respectă preferințele canalului, regulile de suprimare și orele de liniște configurate.
  • Eșecul livrării: Adresele invalide, erorile furnizorului și reîncercările produc rezultate trasabile fără retrimiteri necontrolate.
  • Acțiunea clientului: Fiecare link de urmărire și de asistență ajunge la destinația dorită pe mobil.

Începeți cu un grup limitat de expedieri și examinați istoricul mesajelor împreună cu istoricul urmăririi. Oferiți personalului de asistență o modalitate de a vedea ce a primit clientul. Mențineți un control de pauză, astfel încât echipa să poată opri o regulă defectuoasă fără a dezactiva urmărirea expedierilor.

Monitorizați eligibilitatea notificărilor, încercările de trimitere, acceptarea de către furnizor, erorile, duplicatele și întârzierea dintre primirea evenimentului și trimiterea mesajului. Acceptarea de către furnizor nu demonstrează că un client a citit mesajul, iar ratele de deschidere singure nu demonstrează că fluxul de lucru a fost util.

Pentru a evalua impactul asupra clienților, comparați ratele de contact legate de expedieri folosind o definiție consecventă și grupuri de expedieri comparabile. Luați în calcul modificările privind mixul transportatorilor, problemele de livrare și volumul comenzilor înainte de a atribui o schimbare notificărilor.

Întrebări frecvente

Ar trebui trimisă o confirmare de expediere atunci când este creată eticheta?

Puteți trimite o actualizare privind crearea etichetei, dar descrieți situația cu exactitate. Spuneți că detaliile de expediere sunt disponibile sau că expedierea este pregătită. Păstrați formularea care confirmă preluarea de către transportator pentru un eveniment care susține acest lucru.

Pot funcționa notificările de expediere fără o integrare API?

Da. Un flux de lucru bazat pe aplicație poate gestiona conexiunea și regulile de notificare prin interfața sa. Verificați evenimentele, canalele, controalele șabloanelor și gestionarea excepțiilor disponibile în configurația aleasă. Integrările personalizate sunt mai potrivite atunci când sistemele existente necesită rutare specializată sau logică de decizie.

Câte notificări ar trebui să primească fiecare expediere?

Nu există un număr ideal universal. Începeți cu repere distincte și utile și cu excepții orientate spre acțiune. Suprimați scanările repetate din timpul tranzitului și adăugați mesaje numai atunci când oferă informații de care clientul are nevoie.

Ce ar trebui să se întâmple atunci când urmărirea nu se mai actualizează?

Aplicați o regulă de verificare adecvată serviciului, în loc să declarați expedierea pierdută. Verificați ultimul eveniment, estimarea livrării dacă este disponibilă și procesul operațional relevant. Trimiteți clientului o actualizare numai atunci când aceasta adaugă informații verificate sau un pas următor util.

Poate o notificare de livrare să închidă automat un caz de asistență?

O scanare de livrare poate actualiza un caz, dar nu ar trebui să rezolve automat raportarea de către client a nelivrării. Tratați starea de livrare a transportatorului și problema clientului ca înregistrări separate, apoi urmați procesul de investigare.

Surse