Oston jälkeinen teknologiapino: seuranta, palautukset, tuki ja niiden yhteys
Oston jälkeinen teknologiapino yhdistää lähetysseurannan, palautusten hallinnan, asiakastuen sekä järjestelmät, joihin tilaus- ja maksutiedot tallennetaan. Verkkokauppatiimien tavoitteena ei ole hankkia erillistä sovellusta jokaiseen tehtävään. Tavoitteena on saada toimitustapahtumat, asiakkaiden pyynnöt ja hyvityspäätökset siirtymään järjestelmien välillä niin, ettei asiayhteys katoa tai ristiriitaisia toimintoja käynnisty.
Tässä oppaassa selitetään, mistä kunkin kerroksen tulisi vastata, miten tiedon tulisi kulkea niiden välillä ja miten yhteydet testataan ennen teknologiapinon laajentamista. Hyödyllisin lähtökohta on yksi asiakaspolku: tilaus lähetetään, jokin muuttuu, asiakas tarvitsee apua ja jonkun on päätettävä, mitä seuraavaksi tapahtuu.
Rakenna vastuiden, älä sovellusluettelon, ympärille
Seurantatyökalu voi ilmoittaa lähetyksen etenemisestä, mutta lähetyspäivitys ei ole täydellinen tilaustietue. Palautusportaali voi vastaanottaa pyynnön, mutta pyyntö ei todista, että hyvitys on suoritettu. Tukihenkilö voi hyväksyä poikkeuksen, mutta päätöksen on silti saavuttava järjestelmään, joka toteuttaa sen.
Erot ovat tärkeitä, koska yhdistetyt järjestelmät voivat näyttää samat tiedot ilman, että niillä on sama oikeus muuttaa niitä. Määritä jokaiselle tietueelle auktoritatiivinen järjestelmä ja ohjaa muut järjestelmät viittaamaan siihen.
| Kerros | Suositeltu vastuu | Vaihdettavat tiedot |
|---|---|---|
| Kauppapaikka tai tilaustenhallintajärjestelmä | Tilauksen tunniste, ostetut tuotteet, toimitusten kohdistukset ja tilauksen kaupallinen tila | Tilaustunnukset, rivituotetunnukset, määrät, asiakasviitteet ja lähetysyhteydet |
| Lähetysseuranta | Lähetyksen näkyvyys ja toimitustapahtumien tulkinta | Rahdinkuljettajan viitteet, seurantatunnukset, tapahtuma-ajat, tilat ja poikkeukset |
| Palautusten hallinta | Palautuspyynnöt, käytäntötarkistukset, hyväksytyt tuotteet ja palautustyönkulun tila | Palautustunnukset, tuotemäärät, syyt, hyväksynnät ja tarkastustulokset |
| Asiakastuki | Asiakaskeskustelut, selvitykset ja hyväksytyt poikkeukset | Asiakastukipyyntöjen tunnukset, olennainen tilaustilanne, päätökset ja eskaloinnin omistajuus |
| Varasto- ja maksujärjestelmät | Fyysinen vastaanotto ja tarkastus; taloudellinen toteutus ja täsmäytys | Vastaanottotulokset, tuotteiden käsittelypäätökset, hyvitysviitteet ja tapahtumien tulokset |
Tämä on suositeltu omistajuusmalli, ei vaatimus viiden erillisen tuotteen käyttämisestä. Yksi alusta voi kattaa useita vastuita. Ratkaisevaa on, että jokaisella tärkeällä tilalla on selkeä omistaja ja että muut järjestelmät pystyvät erottamaan pyydetyn toiminnon suoritetusta toiminnosta.
Seurannan tulee selittää lähetyksen eteneminen tekemättä kaupallisia päätöksiä
Seurantakerros yhdistää rahdinkuljettajan toiminnan asiakkaan tilaukseen. Sen tulee auttaa asiakkaita ymmärtämään, missä heidän pakettinsa on, ja henkilöstöä tunnistamaan, milloin lähetys vaatii huomiota. Postitoimituksissa postin seuranta on yksi osa näkyvyyskerrosta; laajemman arkkitehtuurin on huomioitava myös tilaukset, joissa on useita paketteja tai eri rahdinkuljettajia.
Muodosta tilaukset ja lähetykset erillisinä. Kahden paketin tilauksessa yksi paketti voi olla toimitettu ja toinen edelleen matkalla. Koko tilauksen merkitseminen toimitetuksi ensimmäisen toimitustapahtuman jälkeen voi johtaa harhaanjohtaviin ilmoituksiin, virheellisiin tukivastauksiin ja epäselvyyteen siitä, mitkä tuotteet voidaan palauttaa.
Säilytä alkuperäinen tapahtuma yksinkertaistetun tilan rinnalla
Asiakkaalle näkyvä tila, kuten ”matkalla”, on helpompi lukea kuin rahdinkuljettajan tapahtumavirta. Tukitiimit saattavat silti tarvita alkuperäisen tapahtumatekstin, sijainnin ja aikaleiman ongelman selvittämiseksi. Säilytä mahdollisuuksien mukaan molemmat näkymät ja erota toisistaan aika, jolloin rahdinkuljettaja ilmoitti tapahtuman tapahtuneen, ja aika, jolloin järjestelmäsi vastaanotti sen.
Seurantapoikkeaman tulisi yleensä käynnistää tarkistus tai määritetty työnkulku, ei automaattisesti oikeuttaa hyvitykseen. Viivästys, toimitusyritys ja toimitetuksi ilmoitettu mutta vastaanottamatta jäänyt paketti edellyttävät erilaisia toimia. Ratkaisun tulee perustua kauppiaan käytäntöön ja selvitysprosessiin.
Määritä ilmoitusten omistajuus
Päätä, mikä järjestelmä lähettää kunkin viestin. Jos kauppapaikka, seurantajärjestelmä ja tukiautomaatio lähettävät kaikki toimituspäivityksiä, asiakas voi saada päällekkäisiä tai ristiriitaisia viestejä. Ylläpidä ilmoituskarttaa, jossa määritetään laukaisin, lähettäjä, kohderyhmä, estoehdot ja kohdelinkki.
Esimerkiksi lähetysviivästystä koskevan viestin ei pidä luvata korvaavaa tuotetta, ellei korvaavaa tuotetta ole todella hyväksytty. Viestin tarkoitus voi olla vain selittää uusin tila ja tarjota reitti avun saamiseen.
Palautukset tarvitsevat tuotetason asiayhteyden ja erillisen taloudellisen tilan
Palautus alkaa tuotteesta ja käytäntöpäätöksestä, ei vain seurantatunnuksesta. Palautuskerroksen on tiedettävä, mitä ostettiin, mitkä määrät ovat edelleen palautuskelpoisia ja vaikuttaako aiempi palautus tai hyvitys jo pyyntöön.
Määritä ennen automaation toteuttamista tapahtumat, jotka vievät palautusta eteenpäin. Käytännöllisessä työnkulussa voidaan erottaa pyynnön lähettäminen, pyynnön hyväksyminen, paketin luovuttaminen kuljetukseen, paketin vastaanottaminen, tarkastuksen valmistuminen ja hyvityksen pyytäminen. Todellisten vaiheiden tulee vastata yrityksen toimintatapaa.
Älä yhdistä näitä vaiheita yhdeksi ”palautettu”-merkinnäksi. Palautuspaketin kuljetustapahtuma ei yksinään osoita, että varastohenkilöstö on tarkastanut sen sisällön. Vastaavasti hyvityspyyntö ei osoita, että maksujärjestelmä käsitteli hyvityksen onnistuneesti.
- Osittaisissa palautuksissa: vaihda tuotetason tunnisteet ja määrät, älä vain tilauksen kokonaissummaa.
- Vaihdossa: määritä, kuka varaa varaston, luo korvaavan tilauksen ja käsittelee mahdollisen hintaeron.
- Ennakkohyvityksissä: määritä kelpoisuuden synnyttävä tapahtuma, riskitarkistukset, hyväksyntävaltuus ja poikkeusprosessi.
- Käytäntöpoikkeuksissa: tallenna, kuka hyväksyi poikkeuksen ja minkä jatkotoimen se sallii.
Määritä kelpoisuus julkaistun käytännön ja sovellettavien velvoitteiden perusteella. Ohjelmiston asetusten tulee toteuttaa nämä päätökset, ei muodostaa huomaamatta omaa käytäntöään.
Tuki on poikkeusten päätöksentekokerros
Tukityötilan tulee tuoda yhteen riittävä asiayhteys tapauksen ratkaisemiseksi ilman, että tukihenkilöiden on koottava tilausta useista hallintapaneeleista. Tämä ei tarkoita jokaisen tietueen kopioimista jokaiseen tukipyyntöön.
Hyödyllinen tilausnäkymä sisältää lähetysyhteydet, viimeisimmät olennaiset seurantatapahtumat, avoimet palautukset, hyvitysten tulokset ja aiemmat päätökset. Sen tulee näyttää myös, milloin tiedot on viimeksi päivitetty. Ilman aikaleimaa näytetty vanha tila voi näyttää ajantasaiselta ja johtaa tukihenkilön antamaan väärän neuvon.
Erota lukuoikeudet toimintavaltuuksista. Monet tukihenkilöt voivat tarvita pääsyn hyvityshistoriaan, mutta harvemmilla tulee olla oikeus myöntää hyvitys tai ohittaa palautuskelpoisuus. Rahaan tai varastoon vaikuttavilla toimilla tulee olla tarkastusjälki ja toistamisen estävät suojaukset.
Ohjaa tapaukset niiden edellyttämän työn mukaan. Lähetys, joka ei ole liikkunut äskettäin, voi vaatia logistiikkaselvityksen. Hylätty hyvitystapahtuma voi vaatia maksutoimintojen käsittelyä. Palautus, jonka sisältö poikkeaa odotetusta, voi vaatia varaston tarkistuksen. Tukipyynnön luokka on hyödyllinen vain, jos se johtaa nimettyyn omistajaan ja seuraavaan vaiheeseen.
Näin järjestelmät yhdistetään: seuraa yhtä poikkeusta alusta loppuun
Tarkastellaan esimerkkitilausta, jossa on kaksi erillisissä paketeissa lähetettyä tuotetta. Yksi paketti saapuu, mutta toisessa ilmenee toimituspoikkeama. Asiakas ottaa yhteyttä tukeen ja palauttaa myöhemmin toimitetun tuotteen.
- Tilausjärjestelmä luo yhteydet. Jokainen tuoterivi yhdistetään oikeaan lähetykseen. Tuki näkee, ettei toimittamaton tuote ole toimitetussa paketissa.
- Seurantakerros vastaanottaa poikkeaman. Se säilyttää lähetysviitteen ja tapahtumatiedot. Työnkulku luo tai päivittää selvityksen sen sijaan, että koko tilaus käsiteltäisiin kadonneena.
- Tuki tarkistaa tapauksen. Tukihenkilö tarkistaa asiaankuuluvan lähetyksen ja tallentaa sovitun seuraavan vaiheen. Jos korvaava tuote hyväksytään, tilausjärjestelmä saa erillisen ohjeen sen luomiseen.
- Asiakas pyytää toimitetun tuotteen palautusta. Palautusjärjestelmä tarkistaa tuotteen ja määrän tilausta ja aiempaa palautustoimintaa vasten.
- Varasto vastaanottaa ja tarkastaa palautuksen. Tarkastustulos liitetään palautustietueeseen, eikä sitä päätellä pelkästään paketin seurannasta.
- Taloudellinen työnkulku toteuttaa hyväksytyn ratkaisun. Hyvityksen tulos kirjoitetaan takaisin, jotta tuki ja asiakkaalle näkyvä palautusnäkymä eivät sekoita hyväksyntää toteutukseen.
Yhteydet toimivat onnistuneesti, kun jokainen osapuoli näkee saman lopputuloksen ilman oikeutta korvata oman vastuunsa ulkopuolisia tietueita.
Integraation yksityiskohdat, jotka on testattava myyntiesittelyn sijaan
Yhteiset tunnisteet ja tietueiden yhdistäminen
Käytä pysyviä sisäisiä tunnisteita tilausten, tuoterivien, lähetysten, palautusten ja tukipyyntöjen yhdistämiseen. Älä luota pelkästään sähköpostiosoitteeseen tai näkyvään tilausnumeroon. Yhdistämissääntöjen tulee huomioida seurantatunnusten tulkinta rahdinkuljettajan yhteydessä sekä se, että asiakkaalla voi olla useita aktiivisia tilauksia.
Tapahtumien toimitus ja täsmäytys
Webhookit voivat tuetuissa tapauksissa ilmoittaa vastaanottavalle järjestelmälle tapahtuman syntymisestä. Ne eivät poista tarvetta käsitellä puuttuvia, viivästyneitä, toistuvia tai väärässä järjestyksessä saapuvia viestejä. Selvitä, miten epäonnistuneet toimitukset yritetään uudelleen ja miten tiimisi voi palauttaa tapahtumat käyttökatkon jälkeen.
Tee toistuvasta käsittelystä turvallista. Jos esimerkiksi sama palautuksen hyväksyntä vastaanotetaan kahdesti, sen ei pidä johtaa kahteen hyvitykseen. Täsmäytystyön tulee myös verrata tärkeitä tietueita järjestelmien välillä, jotta väliin jäänyt ilmoitus ei jätä palautusta tai hyvitystä pysyvästi jumiin.
Todennus ja asiakastietojen rajat
Seurantahaku, palautuspyyntö ja tukihenkilön myöntämä hyvitys tarvitsevat erilaiset käyttöoikeustasot. Päätä, miten asiakkaat todistavat voivansa tarkastella tai muuttaa tilausta, miten henkilöstön oikeudet määritetään ja mitä henkilötietoja kukin yhdistetty sovellus todella tarvitsee.
Tarkista toteutuksen aikana webhookien todennus, tunnistetietojen säilytys, käyttöoikeuksien peruminen, säilytysasetukset ja tarkastuslokit. Vältä täydellisten asiakastietueiden kopioimista lokeihin, jos sisäinen viite riittää.
17TRACKin rooli arkkitehtuurissa
17TRACKiin keskittyvässä arvioinnissa aloita työhön sopivasta tuotteen lähtöpisteestä. kuluttajien seurantaverkkosivusto soveltuu yksittäisen lähetyksen hakuun. Tilausseurantasovellusta arvioivat kauppiaat voivat tutustua 17TRACK Shopify -listaukseen. Mukautettua yhteyttä suunnittelevat tiimit voivat tutustua Tracking API -tietoihin ja API-dokumentaatioon. Palautusvaatimukset tulee arvioida erikseen 17RETURNS-ratkaisun osalta.
Nämä ovat asiaankuuluvia arviointireittejä, eivät todiste siitä, että kaikki tämän oppaan yhteydet ovat valmiiksi käytettävissä. Vahvista suunnitellun tuotteen tarkat tietokentät, tuetut työnkulut, käyttöoikeudet ja kaupalliset ehdot. Älä oleta, että toisiinsa liittyvien tuotteiden valitseminen synkronoi automaattisesti tukipyynnöt, varastotarkastukset tai maksutapahtumien tulokset.
Ota käyttöön pienin todellisen puutteen korjaava työnkulku
Aloita nykyisen toimintasi kalleimmasta tiedonsiirtokohdasta. Jos tukihenkilöt etsivät lähetyksen tilaa toistuvasti käsin, aseta seurannan asiayhteys tuen yhteydessä etusijalle. Jos asiakkaat eivät tiedä, onko palautus vastaanotettu tai hyvitetty, aseta palautuksen, varaston ja maksun välinen yhteys etusijalle.
Ennen uuden sovelluksen hankkimista kartoita kauppapaikassa ja tukijärjestelmässä jo olevat ominaisuudet. Lisää erikoistyökalu, kun se ratkaisee määritellyn puutteen, ja varmista koko työnkulku sen sijaan, että arvioisit sitä vain asiakkaalle näkyvän sivun perusteella.
Hyödyllisen hyväksymistestin tulee sisältää:
- Useisiin lähetyksiin jaettu tilaus.
- Seurantapäivitys, joka saapuu uudemman tapahtuman jälkeen.
- Toistuva tapahtuma, joka ei saa toistaa taloudellista toimintoa.
- Osittainen palautus tilauksessa, josta on aiempi hyvitys.
- Epäonnistunut hyvitys, joka näkyy edelleen tuelle.
- Tilapäinen integraatiokatko ja sitä seuraava palautuminen.
- Manuaalinen poikkeus, joka ohittaa normaalin työnkulun tallennetulla syyllä.
Määritä jokaiselle epäonnistuneelle testille omistaja ja selvitä, miten henkilöstö toimii integraation ollessa poissa käytöstä. Manuaalinen varamenettely kuuluu suunnitteluun, eikä se tarkoita automaation epäonnistumista.
Mittaa tuloksia tiedonsiirtokohtien yli
Seuraa toimituksiin liittyviä yhteydenottoja lähetettyä tilausta kohden, palautusten käsittelyaikaa, ratkaisemattomia integraatiovirheitä sekä hyvityksen hyväksynnän ja vahvistetun toteutuksen välistä aikaa. Määrittele jokainen mittari täsmällisesti. Erota esimerkiksi palautuksen kuljetusaika varaston käsittelyajasta, jotta vastuullinen tiimi voi toimia tuloksen perusteella.
Vertaa mahdollisuuksien mukaan samanlaisia ajanjaksoja ja asiakasryhmiä. Tukiyhteydenottojen väheneminen ei automaattisesti tarkoita parannusta, jos asiakkaat ovat samalla menettäneet pääsyn apuun. Yhdistä tehokkuusmittarit ratkaisemattomiin tapauksiin, toistuviin yhteydenottoihin ja näyttöön siitä, että asiakkaat saivat oikean ratkaisun.
UKK
Tarvitsevatko pienet kaupat erilliset seuranta-, palautus- ja tukityökalut?
Eivät välttämättä. Aloita jo käytettävissä olevista ominaisuuksista ja tunnistettavista toimintaongelmista. Erilliset työkalut ovat hyödyllisiä, kun nykyinen ratkaisu ei tarjoa riittävää näkyvyyttä, käytäntöjen hallintaa tai luotettavia tiedonsiirtoja. Useammat sovellukset ilman selkeää omistajuutta voivat lisätä manuaalista työtä.
Pitäisikö seurantatapahtumien käynnistää hyvitykset automaattisesti?
Vain nimenomaisesti hyväksytyssä työnkulussa ja asianmukaisten tarkistusten jälkeen. Lähetystapahtumat kuvaavat liikkumista tai toimitustoimintaa; ne eivät välttämättä osoita hyvityskelpoisuutta. Pidä käynnistävä tapahtuma, hyväksyntäpäätös ja taloudellinen toteutus erillään.
Riittääkö API-yhteys saamaan kaksi työkalua toimimaan yhdessä?
Ei. Yhteys tarvitsee myös yhteensopivat tunnisteet, kenttäkartoituksen, käyttöoikeudet, virheenkäsittelyn ja säännöt ristiriitaisille päivityksille. Vahvista, mitä tietueita voidaan lukea tai muuttaa, ja testaa liiketoiminnan työnkulku alusta loppuun.
Voidaanko toimitetuksi merkitty palautus näyttää hyvitetyksi?
Ei pelkästään tämän näytön perusteella. Palautusosoitteeseen toimitus, varaston vastaanotto, tarkastus, hyvityksen hyväksyntä ja hyvityksen onnistunut toteutus ovat eri tapahtumia. Asiakasviestien tulee ilmoittaa vaihe, joka on todella vahvistettu.
Kenen tulisi omistaa oston jälkeinen teknologiapino?
Verkkokaupan tai operaatioiden johtaja on käytännöllinen kokonaisomistaja, ja tuki-, logistiikka-, talous- ja tekniset tiimit vastaavat omista työnkuluistaan. Yhden henkilön tulee koordinoida järjestelmien välisiä vikoja, jotta ongelmat eivät jää osastojen väliin.
Lähteet
Seuraavat viralliset tuote- ja dokumentaatioresurssit ovat edellä käsiteltyjen 17TRACK-arviointireittien lähtökohtia. Vahvista toteutuskohtaiset vaatimukset asiaankuuluvasta dokumentaatiosta ja tuotteen ehdoista.
