Kuinka automatisoida lähetysilmoitukset: laukaisimet, kanavat ja mallipohjat kuudessa vaiheessa

Voit automatisoida lähetys-ilmoitukset yhdistämällä lähetyksen tapahtumat tilaustietoihisi, määrittämällä, mitkä tilamuutokset edellyttävät viestiä, valitsemalla sallitun toimituskanavan ja liittämällä mallin jokaiseen laukaisimeen. Lisää ennen käyttöönottoa myös kaksoiskappaleiden esto, poikkeusten käsittely ja testaus. Alla olevat kuusi vaihetta näyttävät verkkokauppatiimeille, kuinka rakennetaan työnkulku, joka tarjoaa asiakkaille hyödyllisiä päivityksiä lähettämättä toistuvia tai harhaanjohtavia ilmoituksia.

Tämä opas on tarkoitettu kauppiaille, verkkokauppojen operatiivisille tiimeille ja kehittäjille, jotka vastaavat oston jälkeisestä viestinnästä. Suositeltu lähtökohta on pieni joukko luotettavia ilmoituksia: kuljetusyhtiön vastaanotto, toimitukseen lähtö, toimitettu sekä poikkeukset, jotka edellyttävät asiakkaan toimia. Lisää muita viestejä vain, kun ne vastaavat erilliseen asiakkaan kysymykseen.

1. Yhdistä seurantatapahtumat oikeaan tilaukseen ja vastaanottajaan

Rahtikirja, kuljetusyhtiön skannaus ja asiakas-ilmoitus ovat eri asioita. Rahtikirjan luominen ei tarkoita, että kuljetusyhtiö olisi vastaanottanut paketin. Automaation tulee säilyttää tämä ero alusta alkaen.

Aloita tunnistamalla järjestelmä, joka vastaa ilmoituspäätöksistä. Se voi olla kauppasi ilmoitustyönkulku, seurantasovellus tai tilausjärjestelmääsi yhdistetty palvelu. Määritä yksi vastuujärjestelmä kutakin viestityyppiä varten, jotta useat järjestelmät eivät lähetä itsenäisesti samaa päivitystä.

Kaksi käytännöllistä toteutustapaa ovat:

• Sovelluspohjainen käyttöönotto: Käytä verkkokaupan seurantasovellusta, kun tiimisi haluaa määrittää tuetut tapahtumat ja asiakkaille näkyvät viestit rakentamatta koko integraatiota itse. Shopify-kauppiaille 17TRACK-sovelluslistaus on sopiva lähtökohta lähetysseurannan ja ilmoitustyönkulkujen arviointiin. Varmista ennen sääntöjen määrittämistä tarkat laukaisimet, kanavat, mukautusmahdollisuudet ja suunnitelmavaatimukset.
• API-pohjainen käyttöönotto: Käytä seuranta-integraatiota, kun lähetyksen tapahtumien on syötettävä olemassa olevaan tilausjärjestelmään tai mukautettuun viestityönkulkuun. 17TRACK Tracking API ja sen virallinen dokumentaatio ovat olennaisia toteutusviitteitä. Varmista käyttämäsi integraation tapahtumien toimitusmekanismi, tietokentät, tunnistautuminen ja uudelleenyritysten toiminta. Seurantatietojen vastaanottaminen ja asiakasviestien lähettäminen ovat eri vastuualueita.

Valitsemastasi tavasta riippumatta yhdistä jokainen lähetys oikeaan tilaukseen ja vastaanottajaan. Hyödyllinen sisäinen tietue sisältää:

• Tilauksen viitteen ja lähetyksen tunnisteen.
• Seurantanumeron ja kuljetusyhtiön tunnisteen, jos saatavilla.
• Lähetykseen sisältyvät tuotteet, erityisesti jaetuissa tilauksissa.
• Asiakkaan yhteystiedot, kielen, aikavyöhykkeen ja kanavatoiveet.
• Viimeisimmän hyväksytyn lähetysstatuksen ja tapahtuman ajankohdan.
• Ilmoitushistorian, mukaan lukien lähetys, jota kukin viesti koski.

Pidä tapahtuman ajankohta erillään ajasta, jolloin järjestelmäsi vastaanotti päivityksen. Viivästynyt skannaus ei saa automaattisesti muuttua uudeksi asiakas-ilmoitukseksi. Säilytä myös kuljetusyhtiön alkuperäinen kuvaus normalisoidun statuksen rinnalla, jotta tukitiimi voi tutkia epäselvät tapahtumat.

2. Määritä merkityksellisiä lähetysmuutoksia vastaavat laukaisimet

Laukaisimen tulee edustaa asiakkaalle merkityksellistä muutosta, ei jokaista uutta seurantatietuetta. Useat terminaaliskannaukset voivat kaikki tarkoittaa “kuljetuksessa”. Ilmoituksen lähettäminen jokaisesta niistä aiheuttaa hälyä auttamatta asiakasta päätöksenteossa.

Yhdistä saapuvat tapahtumat pieneen joukkoon ymmärrettäviä statuksia. Seuraava taulukko on ehdotettu työnkulku, ei yleispätevä kuljetusyhtiöiden statusluettelo.

Käsittele poikkeuksia huolellisemmin kuin rutiininomaisia virstanpylväitä. Epäonnistunut toimitusyritys, tulliongelma, osoiteongelma ja lähetyksen palautuminen lähettäjälle voivat edellyttää erilaisia ohjeita. Jos tapahtuma ei kerro, mitä asiakkaan tulisi tehdä, älä keksi ratkaisua.

Valitse “ei viimeaikaista päivitystä” -säännölle palveluun ja reittiin sopiva kynnysarvo yhden yleisen aikavälin sijaan. Skannausten puuttuminen ei todista paketin kadonneen. Ohjaa epävarmat tapaukset sisäiseen tarkistusjonoon tai lähetä neutraali päivitys, joka kuvaa tarkasti tiedossa olevat asiat.

Pidä arvioidut toimituspäivät erillään lähetysstatuksista. Sisällytä arvio vain, kun sinulla on luotettava lähde, ilmoita sen olevan arvio ja vältä puuttuvien tietojen korvaamista lasketulla lupauksella, jota toimintasi ei pysty täyttämään.

3. Valitse kanavat ja määritä yhteydenottosäännöt

Käytä kanavaa, koska se sopii viestiin ja asiakkaan toiveisiin, ei vain siksi, että se on saatavilla. Sähköposti on käytännöllinen lähtökohta yksityiskohtaisille päivityksille. Nopeammasta kanavasta voi olla hyötyä aikaherkkään toimintaan, mutta vain silloin, kun lupa, palveluntarjoajan säännöt ja paikalliset vaatimukset sallivat sen.

• Sähköposti: Sopii tilaustietoihin, seurantalinkkeihin, jaettujen lähetysten selityksiin ja tukiohjeisiin. Sisällytä tekstiversio ja tarkista mobiilinäkymä.
• SMS: Hyödyllinen lyhyille, toimintaan ohjaaville ilmoituksille, kun se on sallittua. Tunnista lähettäjä, pidä viesti kohdennettuna ja vältä tarpeettomien tilaustietojen paljastamista.
• Push-ilmoitukset: Sopivat, kun asiakkaat käyttävät sovellustasi ja ovat sallineet ilmoitukset. Linkitä kyseiseen lähetykseen yleisen etusivun sijaan.
• Viestisovellukset: Harkitse niitä, kun asiakkaat käyttävät kanavaa jo ennestään ja toteutuksesi täyttää alustan lupa- ja viestivaatimukset.
• Seurantasivu: Käytä sitä yksityiskohtaisten tietojen kohteena. Se täydentää lähteviä ilmoituksia, mutta ei korvaa ilmoitusta, kun asiakkaan on toimittava.

Dokumentoi kanavien välinen suhde. Voit esimerkiksi käyttää sähköpostia rutiininomaisiin virstanpylväisiin ja sallittua mobiilikanavaa toimia edellyttävään toimitusongelmaan. Älä lähetä jokaista tapahtumaa automaattisesti jokaisen saatavilla olevan kanavan kautta.

Määritä hiljaisten aikojen käsittely ja varakanavakäytäntö. Tilapäinen sähköpostivirhe ei saa automaattisesti antaa lupaa SMS-viestin lähettämiseen. Tarkista ennen kanavan vaihtamista, että sinulla on asianmukaiset yhteystiedot ja lupa eikä toinen järjestelmä ole jo lähettänyt viestiä.

Pidä lähetyspäivitykset operatiivisina. Mainossisällön lisääminen voi vaikuttaa siihen, miten viestiä käsitellään sovellettavien sääntöjen nojalla. Yhdysvalloissa FTC:n CAN-SPAM-ohje selittää, että viestin ensisijainen tarkoitus on tärkeä, kun kaupallinen ja tapahtumaperusteinen sisältö yhdistetään. Älä oleta, että jokainen tilauksen mainitseva viesti on vapautettu kaupallisten sähköpostien vaatimuksista.

4. Rakenna mallit selkeällä varakäyttäytymisellä

Jokaisen mallin tulee vastata kolmeen kysymykseen: Mitä tapahtui? Mitä se tarkoittaa tämän lähetyksen kannalta? Mitä asiakkaan pitäisi tehdä seuraavaksi? Käytä ehdollisia kenttiä, jotta puuttuvat tiedot poistuvat siististi eivätkä jätä rikkinäisiä paikkamerkkejä.

Alla olevat esimerkit ovat lähtömalleja. Hakasulkeissa olevat muuttujat ovat havainnollistavia eivätkä tietyn alustan mallisyntaksia.

Kuljetusyhtiön vastaanottoviesti sähköpostitse

Aihe: Tilauksesi [order_number] lähetys on matkalla

Hei [first_name],

[carrier_name] on vastaanottanut tilauksen [order_number] lähetyksesi. Voit seurata sen etenemistä täällä: [tracking_link].

[Jos luotettava arvio on saatavilla: Arvioitu toimitus: [estimated_delivery_date]. Tämä arvio voi muuttua.]

[Jos tilaus on jaettu: Tämä lähetys sisältää tuotteet [shipment_items]. Tilauksesi muut tuotteet saavat erilliset seurantapäivitykset.]

Toimitukseen lähtenyt -viesti

Tilauksesi [order_number] lähetys on viimeisimmän kuljetusyhtiön päivityksen mukaan lähtenyt toimitukseen. Tarkista sen eteneminen ja saatavilla olevat toimitustiedot: [tracking_link].

Älä lisää taattua saapumisaikaa, ellei toiminnallasi ole vankkaa perustetta lupaukselle. “Toimitukseen lähtenyt” on ilmoitettu status, ei takuu siitä, että toimitus valmistuu samana päivänä.

Poikkeusviesti, jossa vahvistettu seuraava vaihe

Aihe: Toimituspäivitys tilaukselle [order_number]

Kuljetusyhtiö ilmoitti lähetyksellesi seuraavan ongelman: [plain_language_issue]. [verified_next_step]. Katso viimeisimmät tiedot täällä: [tracking_link]. Jos tarvitset apua, ota yhteyttä osoitteessa [support_link].

Jos seuraavaa vaihetta ei ole vahvistettu, korvaa lause seuraavalla: “Meillä ei vielä ole vahvistettua seuraavaa vaihetta. Tarkista päivitykset seurantาสivulta tai ota yhteyttä tukitiimiimme.” Sano tiimisi tutkivan asiaa vain, jos tarkistus on todella määrätty tehtäväksi.

Toimitettu-sähköposti

Aihe: Lähetyksesi on merkitty toimitetuksi

[carrier_name] merkitsi tilauksen [order_number] lähetyksesi toimitetuksi [delivery_date]. Katso mahdolliset toimitustiedot täällä: [tracking_link]. Jos et löydä lähetystä, ota yhteyttä osoitteessa [support_link], jotta voimme auttaa seuraavien vaiheiden tarkistamisessa.

Käytä jaetuissa tilauksissa lähetyskohtaisia ilmaisuja. “Tilauksesi on saapunut” voi olla harhaanjohtava, jos toinen paketti on edelleen kuljetuksessa. Jos kuljetusyhtiön nimi, päivämäärä tai asiakkaan nimi puuttuu, käytä testattua vaihtoehtoista lausetta tyhjän kentän näyttämisen sijaan.

5. Lisää suojaukset päällekkäisiä, vanhentuneita ja harhaanjohtavia viestejä vastaan

Automaatio tarvitsee tietueen jo tehdyistä toimista. Työnkulku, joka lähettää viestin aina tapahtuman saapuessa, voi toistaa ilmoituksia uudelleenyritysten jälkeen tai toimittaa vanhentuneita tietoja uudemman virstanpylvään jälkeen.

• Estä kaksoiskäsittely: Käytä vakaata tapahtumatunnistetta, jos sellainen on saatavilla. Muussa tapauksessa määritä deduplikointiavain sopivista kentistä, kuten lähetyksestä, tapahtumatyypistä ja tapahtuman ajankohdasta. Tallenna erikseen, onko vastaava ilmoitus jo ajoitettu tai lähetetty.
• Estä statuksen toistuminen: Useiden samaan asiakasstatukseen yhdistettyjen skannausten ei tule automaattisesti tuottaa useita viestejä.
• Tarkista tapahtuman merkityksellisyys ennen lähetystä: Arvioi jonossa olevat viestit uudelleen ennen lähettämistä. Estä vanha kuljetuksessa-ilmoitus, jos toimitus on sittemmin ilmoitettu.
• Käsittele korjaukset harkitusti: Säilytä alkuperäinen tapahtumahistoria ja tarkista näennäiset takaisinkelaamiset. Älä oleta, että jokainen myöhemmin saapuva tapahtuma on uudempi tai tarkempi.
• Yritä uudelleen turvallisesti: Erota epäonnistunut lähetys tuntemattomasta lopputuloksesta. Käytä tuettuja palveluntarjoajan idempotenssiominaisuuksia vähentääksesi mahdollisuutta, että uudelleenyritys luo uuden viestin.
• Suojaa vastaanottajan yhdistäminen: Älä koskaan yhdistä lähetystä asiakkaaseen pelkän vahvistamattoman seurantanumeron perusteella.
• Eskaloi ratkaisemattomat poikkeukset: Määritä operatiivinen vastuuhenkilö sen sijaan, että lähettäisit asiakkaalle saman varoituksen toistuvasti.

Mukautetuissa integraatioissa noudata palveluntarjoajan dokumentoitua lähestymistapaa tunnistautumiseen, tapahtumien kuittaukseen ja uudelleenyrityksiin. Pidä käsittelylokit hyödyllisinä kopioimatta niihin tarpeettomia henkilötietoja. Seurantalinkit eivät myöskään saa paljastaa muiden asiakkaiden tilauksia tai tietoja enempää kuin vastaanottaja tarvitsee.

Hyödyllinen käsittelyjärjestys on: vahvista tapahtuma, tunnista lähetys, päivitä sen tila, tarkista ilmoituskelpoisuus, valitse sallittu kanava, muodosta malli, aseta viesti jonoon ja tallenna lopputulos. Tarkista kelpoisuus uudelleen lähetysvaiheessa, jos viesti odottaa jonossa.

6. Testaa koko asiakaspolku ja ota käyttöön vaiheittain

Älä arvioi työnkulkua vain sen perusteella, näyttääkö testi-sähköposti oikealta. Testaa koko polku lähetyksen tapahtumasta asiakkaan vastaanottopaikkaan, mukaan lukien virhetilanteet.

• Normaali polku: Vastaanotto, kuljetus, toimitukseen lähtö ja toimitus tuottavat tarkoitetut viestit.
• Toistuva tapahtuma: Saman tapahtuman toistaminen ei luo uutta ilmoitusta.
• Väärässä järjestyksessä saapuva tapahtuma: Viivästynyt kuljetusskannaus ei laukaise vanhentunutta ilmoitusta toimituksen jälkeen.
• Jaettu tilaus: Jokainen viesti yksilöi oikean lähetyksen eikä anna ymmärtää kaikkien tuotteiden saapuneen.
• Puuttuvat kentät: Puuttuva nimi, kuljetusyhtiö, arvio tai tuoteluettelo tuottaa luettavan varatekstin.
• Yhteydenottorajoitukset: Työnkulku noudattaa kanavatoiveita, estämissääntöjä ja määritettyjä hiljaisia aikoja.
• Toimitusvirhe: Virheelliset osoitteet, palveluntarjoajan virheet ja uudelleenyritykset tuottavat seurattavat lopputulokset ilman hallitsemattomia uusintalähetyksiä.
• Asiakkaan toiminta: Jokainen seuranta- ja tukilinkki johtaa mobiilissa oikeaan kohteeseen.

Aloita rajatulla lähetysryhmällä ja tarkista viestihistoria yhdessä seurantahistorian kanssa. Anna tukihenkilöstölle mahdollisuus nähdä, mitä asiakas vastaanotti. Säilytä keskeytysohjaus, jotta tiimi voi pysäyttää virheellisen säännön poistamatta itse lähetysseurantaa käytöstä.

Seuraa ilmoituskelpoisuutta, lähetysyrityksiä, palveluntarjoajan hyväksyntää, virheitä, kaksoiskappaleita sekä tapahtuman vastaanoton ja viestin lähetyksen välistä viivettä. Palveluntarjoajan hyväksyntä ei osoita, että asiakas luki viestin, eivätkä avausprosentit yksin osoita työnkulun auttaneen.

Arvioi asiakasvaikutusta vertaamalla lähetyksiin liittyvien yhteydenottojen määriä yhdenmukaisella määritelmällä ja vertailukelpoisilla lähetysryhmillä. Ota huomioon kuljetusyhtiöiden yhdistelmän, toimitusongelmien ja tilausmäärän muutokset ennen kuin yhdistät muutoksen ilmoituksiin.

UKK

Pitäisikö lähetysvahvistus lähettää, kun rahtikirja luodaan?

Voit lähettää rahtikirjan luomista koskevan päivityksen, mutta kuvaile se tarkasti. Kerro, että toimitustiedot ovat valmiina tai lähetystä valmistellaan. Käytä kuljetusyhtiön hallussa olemisen vahvistavaa ilmaisua vasta, kun sitä tukeva tapahtuma on olemassa.

Voivatko lähetys-ilmoitukset toimia ilman API-integraatiota?

Kyllä. Sovelluspohjainen työnkulku voi käsitellä yhteyden ja ilmoitussäännöt käyttöliittymänsä kautta. Varmista valitussa käyttöönotossa saatavilla olevat tapahtumat, kanavat, mallien hallinta ja poikkeusten käsittely. Mukautetut integraatiot sopivat paremmin, kun olemassa olevat järjestelmäsi edellyttävät erityistä reititystä tai päätöslogiikkaa.

Kuinka monta ilmoitusta kunkin lähetyksen pitäisi saada?

Yhtä yleispätevää ihannemäärää ei ole. Aloita erillisistä, hyödyllisistä virstanpylväistä ja toimia edellyttävistä poikkeuksista. Estä toistuvat kuljetusskannaukset ja lisää viestejä vain, kun ne tarjoavat asiakkaan tarvitsemaa tietoa.

Mitä pitäisi tapahtua, kun seuranta lakkaa päivittymästä?

Sovella palveluun sopivaa tarkistussääntöä sen sijaan, että julistaisit lähetyksen kadonneeksi. Tarkista viimeisin tapahtuma, saatavilla oleva toimitusarvio ja asiaankuuluva operatiivinen prosessi. Lähetä asiakaspäivitys vain, kun se lisää vahvistettua tietoa tai hyödyllisen seuraavan vaiheen.

Voiko toimitettu-ilmoitus sulkea tukitapauksen automaattisesti?

Toimitusskannaus voi päivittää tapauksen, mutta sen ei tule automaattisesti ratkaista asiakkaan ilmoitusta puuttuvasta toimituksesta. Käsittele kuljetusyhtiön toimitusstatus ja asiakkaan ongelma erillisinä tietueina ja noudata tutkintaprosessiasi.

Lähteet

• 17TRACK Shopify -sovelluslistaus — tuoteviite sovelluspohjaisen seuranta- ja ilmoitusratkaisun arviointiin.
• 17TRACK Tracking API — tuoteviite API-pohjaiseen seuranta-integraatioon.
• 17TRACK API -dokumentaatio — toteutusviite tuetun integraatiokäyttäytymisen ja vaatimusten tarkistamiseen.
• FTC: CAN-SPAM Act -vaatimustenmukaisuusopas yrityksille — ohjeita kaupalliseen sähköpostiin ja viesteihin, joissa yhdistyvät tapahtumaperusteinen ja mainonnallinen sisältö.