Oston jälkeistä asiakaskokemusta muovaavat tekoälytrendit: seuranta, tuki ja palautukset

Tekoäly muokkaa oston jälkeistä kokemusta hyödyllisempien lähetyspäivitysten, tilaustietojen kanssa toimivien tukipalveluavustajien ja palautusten työnkulkujen avulla, jotka auttavat tiimejä tulkitsemaan pyyntöjä. Verkkokauppatoimintojen johtajille käytännön mahdollisuus ei ole yksinkertaisesti lisätä chatbotia. Tärkeää on yhdistää luotettavat seurantatiedot, hyväksytyt käytännöt ja hallitut toiminnot, jotta asiakkaat saavat selkeämpiä vastauksia ilman perusteettomia toimituslupauksia tai virheellisiä hyvityspäätöksiä.

Tässä oppaassa keskitytään arvioitaviin toimintamalleihin sen sijaan, että ennustettaisiin käyttöönottoastetta tai luvattaisiin yleispätevää sijoitetun pääoman tuottoa. Vahvin lähtökohta on rajattu asiakasongelma, johon on todennettavissa oleva vastaus: lähetyksen tapahtuman selittäminen, palautuskelpoisuuden tarkistaminen tai tukipyynnön valmistelu ihmisedustajalle.

Erota hyödyllinen tekoäly tavallisesta automaatiosta

Monet oston jälkeisen kokemuksen parannukset eivät edellytä tekoälyä. Ilmoituksen lähettäminen, kun lähetys saavuttaa tietyn tilan, sen tarkistaminen, kuuluuko tilaus palautusajan piiriin, ja tukipyynnön ohjaaminen yksiselitteisen säännön perusteella ovat perinteisiä automaatiotehtäviä.

Tekoälystä tulee hyödyllisempää, kun syöte on epäselvä tai jäsentämätön. Esimerkkejä ovat asiakkaan toimitusongelman kuvauksen tulkitseminen, pitkän tukikeskustelun tiivistäminen tai teknisen seurantatapahtuman kääntäminen selkeälle kielelle. Ennustemalleilla on eri tarkoitus: ne arvioivat lopputulosta, kuten toimitusaikaa, asiaankuuluvien historiallisten ja ajantasaisten tietojen perusteella.

Näillä toiminnoilla ei pitäisi olla samaa päätösvaltaa. Kielimalli voi laatia selityksen, käytäntömoottorin pitäisi määrittää kelpoisuus ja todennetun operatiivisen järjestelmän pitäisi suorittaa hyvitys. Näiden vastuiden pitäminen erillään helpottaa virheiden havaitsemista ja rajaamista.

Seuranta siirtyy tilan näyttämisestä kohti asiayhteyteen perustuvaa selitystä

Seurantasivu voi näyttää tarkan kuljetusyhtiön tapahtuman ja silti jättää asiakkaan hämmentyneeksi. ”Etiketti luotu” ei välttämättä tarkoita, että kuljetusyhtiö on vastaanottanut paketin. Skannausten välinen aukko ei yksinään osoita paketin kadonneen. Tekoälyn avustamat selitykset voivat auttaa asiakkaita ymmärtämään nämä erot, kunhan selitys pysyy todisteiden rajoissa.

Selitä tapahtuma keksimättä seuraavaa tapahtumaa

Hyödyllisen seurantavastauksen pitäisi erottaa kolme asiaa: mitä kuljetusyhtiö ilmoitti, mitä tapahtuma yleensä tarkoittaa ja mitä asiakas voi tehdä seuraavaksi. Sen pitäisi myös säilyttää tapahtuman aikaleima ja ilmoittaa, tuleeko saapumisarvio kuljetusyhtiöltä vai erillisestä ennusteesta.

Perusteltu vastaus voisi esimerkiksi olla: ”Viimeisin kuljetusyhtiön tapahtuma osoittaa, että lähetystiedot on toimitettu. Nouto- tai vastaanottoskannausta ei ole vielä ilmestynyt tähän seurantasyötteeseen.” Tätä ei pitäisi muuttaa muotoon ”Pakettisi on lähtenyt varastosta”, ellei jokin muu varmennettu järjestelmä vahvista kyseistä tietoa.

• Pidä alkuperäinen tapahtuma saatavilla. Selkokielisen yhteenvedon pitäisi täydentää kuljetusyhtiön alkuperäistä seurantatietuetta, ei peittää sitä.
• Näytä tietojen ajantasaisuus. Ilmoita, milloin lähetys tapahtui ja tarvittaessa, milloin tiedot haettiin viimeksi.
• Erota havainto ennusteesta. Ennustettu toimitusaika ei ole vahvistettu ajankohta.
• Käytä selkeää varakieltä. Jos syöte ei ole käytettävissä, kerro, ettei tilaa voitu päivittää, sen sijaan että esittäisit vanhan tapahtuman uutena.

Käsittele toimitusennusteita mitattavan virheen sisältävinä arvioina

Ennustettuja toimitusarvioita kannattaa arvioida, kun toiminnolla on riittävästi asiaankuuluvaa lähetystietohistoriaa ja tapa testata suorituskykyä. Niiden hyödyllisyys riippuu reitistä, palvelusta, saatavilla olevista tapahtumista ja siitä, kuinka hyvin arviointitiedot vastaavat todellisia lähetyksiä.

Vertaa ehdotettua mallia yksinkertaiseen vertailutasoon, kuten yrityksen jo käytettävissä olevaan kuljetusyhtiön arvioon. Mittaa virhe erikseen eri toimituspalveluille ja määränpäille. Yksi keskiarvo voi peittää epäluotettavat tulokset rajat ylittävillä reiteillä tai häiriötilanteissa. Jos ennuste ei ole luotettava tietyn lähetyksen kohdalla, varmennetun tilan näyttäminen ilman uutta arviota voi tarjota paremman asiakaskokemuksen.

Tukipalveluavustajat tarvitsevat operatiivista asiayhteyttä, eivät vain sujuvia vastauksia

”Missä tilaukseni on?” -kysymystä käsittelevä avustaja tarvitsee muutakin kuin seurantatunnuksen. Pyynnöstä riippuen se voi tarvita todennetun pääsyn tilaukseen, toimituksen tilan, lähetyshistorian, sovellettavan toimituslupauksen ja kauppiaan hyväksytyn eskalointikäytännön.

Hakuun perustuva tukipalvelu yhdistää avustajan asiaankuuluviin tietueisiin ja käytäntöasiakirjoihin ennen vastauksen luomista. Tämä voi tehdä vastauksista osuvampia, mutta pelkkä haku ei takaa oikeellisuutta. Järjestelmä voi valita vanhentuneen käytännön, sekoittaa kaksi lähetystä tai tehdä johtopäätöksen, jota haetut tiedot eivät tue.

Rakenna työnkulku varmennuksen ja eskaloinnin ympärille

1. Varmista käyttöoikeus. Vahvista, että asiakkaalla on oikeus tarkastella tilausta, ennen kuin paljastat osoitteita, ostotietoja tai lähetystietoja.
2. Hae asiaankuuluvat tietueet. Yhdistä tilaus, paketti ja asiakkaan pyyntö. Ota ositetut lähetykset huomioon sen sijaan, että olettaisit yhden tilauksen tarkoittavan yhtä pakettia.
3. Määritä sallittu vastaus. Käytä sovellettavaa käytäntöversiota ja erota vahvistetut tosiasiat epävarmoista tulkinnoista.
4. Tarjoa valtuutettu seuraava vaihe. Se voi olla seurantリンクki, tukipyyntö tai palautuspyyntö – ei välttämättä välitön hyvitys.
5. Siirrä asiayhteys eskaloinnin yhteydessä. Anna ihmisedustajalle asiakkaan ongelma, tarkistetut tietueet, tehdyt toimet ja ratkaisematon kysymys.

Aloita edustajan avustamisesta, jos käytäntöpoikkeuksia esiintyy usein tai tilaustiedot ovat epäjohdonmukaisia. Edustajan tarkistama luonnos voi olla hyödyllinen, ennen kuin yritys on valmis itsenäisiin asiakasratkaisuihin. Kun suorat vastaukset ovat käytössä, asiakkailla pitäisi silti olla selkeä reitti ihmistukeen.

Palautusten hallinta hyötyy tulkinnasta, mutta kelpoisuus tarvitsee säännöt

Palautuspyynnöt sisältävät tietoa, jota on vaikea kuvata lyhyellä pudotusvalikolla. ”Se ei sovi” voi viitata kokoon, tuotteen mittoihin tai virheelliseen kuvaukseen. Tekoäly voi auttaa luokittelemaan näitä selityksiä, tiivistämään tukevat tiedot ja tunnistamaan pyynnöt, jotka tarvitsevat tarkennusta.

Tämä tulkinta pitäisi pitää erillään palautuspäätöksestä. Kelpoisuus voi riippua ostopäivästä, tuoteryhmästä, kunnosta, määränpäästä, kauppiaan käytännöstä ja sovellettavista kuluttajan oikeuksista. Avustajan ei pitäisi keksiä poikkeusta tai pitää omaa yhteenvetoaan todisteena asiakkaan kelpoisuudesta.

Käytä tekoälyä tapauksen valmisteluun, älä käytännön hiljaiseen muuttamiseen

Hallittu työnkulku hakee ensin tilauksen ja sovellettavan käytännön. Sen jälkeen se pyytää vain puuttuvat tiedot, suorittaa kelpoisuustarkistukset ja esittää sallitut vaihtoehdot. Tekoäly voi helpottaa keskustelun seuraamista, kun taustalla olevat säännöt määrittävät, mitä voidaan tarjota.

Jos asiakas esimerkiksi ilmoittaa tuotteen olevan vaurioitunut, avustaja voi kerätä kuvauksen ja järjestää toimitetut todisteet. Erillisen työnkulun pitäisi päättää, ovatko tarkastus, vaihto, hyvitys tai ihmisen arviointi asianmukaisia. Kuvien analyysiä ei pitäisi pitää ratkaisevana todisteena vauriosta tai väärinkäytöksestä.

Myös riskipisteytys edellyttää pidättyväisyyttä. Epätavallinen palautusmalli voi oikeuttaa tarkasteluun, mutta se ei osoita petosta. Säilytä valitusreitti, dokumentoi päätösten perustelut ja tarkista, luovatko säännöt perusteettomia esteitä oikeutetuille asiakkaille.

Toimintoja suorittavat avustajat nostavat panoksia

Palautuskäytännön selittämisen ja hyvityksen myöntämisen välillä on merkittävä ero. Kun tekoälyavustaja voi kutsua operatiivisia työkaluja, sen virheet voivat muuttaa tietueita, käyttää rahaa tai paljastaa asiakastietoja.

Käytä käyttöoikeusmallia, joka vastaa kunkin toiminnon seurauksia. Valtuutetun tilaustietueen lukemista, vastauksen luonnostelua, palautuksen pyytämistä, osoitteen muuttamista ja hyvityksen myöntämistä ei pitäisi käsitellä samanarvoisina ominaisuuksina.

• Valvo rajoja mallin ulkopuolella. Työkalujen käyttöoikeudet, käytäntötarkistukset ja hyväksyntävaatimukset pitäisi toteuttaa sovelluslogiikassa.
• Estä päällekkäiset toiminnot. Uudelleenyritykset eivät saa luoda useita hyvityksiä, etikettejä tai korvaavia tilauksia.
• Vahvista merkittävät muutokset. Näytä aiottu toiminto ja olennaiset tiedot ennen suorittamista, kun vahvistus on asianmukainen.
• Säilytä auditointijälki. Tallenna käytetyt tiedot, pyydetty toiminto, sen valtuutus ja tulos.
• Käsittele asiakasviestejä epäluotettavana syötteenä. Viestin tai liitteen sisältämät ohjeet eivät saa ohittaa järjestelmän käyttöoikeuksia tai liiketoimintakäytäntöjä.

NIST AI Risk Management Framework tarjoaa hyödyllisen hallintoviitekehyksen Govern-, Map-, Measure- ja Manage-toimintojensa kautta. Se ei ole sertifikaatti siitä, että tietty avustaja on turvallinen; yritys tarvitsee edelleen omiin työnkulkuihinsa sopivia testejä ja valvontakeinoja.

Rakenna tietoperusta ennen tekoälykerroksen valitsemista

Seurannan, tuen ja palautusten pitäisi liittyä toisiinsa asiakkaiden, tilausten, tuotteiden ja pakettien johdonmukaisen suhteen kautta. Ilman tätä perustaa avustaja voi antaa viimeistellyn vastauksen väärästä lähetyksestä tai soveltaa käytäntöä väärään tuotteeseen.

17TRACK-keskeisessä toteutuksessa tarkista 17TRACK Shopify -listaus kauppiaan seurantakäyttötapausta varten sekä Tracking API ja API-dokumentaatio mukautetun integraation arviointia varten. Palautusten työnkulkuja varten tarkista 17RETURNS. Nämä ovat olennaisia lähtökohtia operatiivisten kerrosten arviointiin; niiden mukanaolo ei tarkoita, että ne tarjoaisivat kaikki tässä oppaassa kuvatut tekoälyominaisuudet.

Kuluttajille suunnattu seurantasivu voi tukea lähetyksen hakua, mutta sen rooli eroaa kauppiaan tukipalveluavustajan tarvitsemasta todennetusta tietojen käytöstä ja toimintojen hallinnasta. Vahvista tarkka integraatiokäyttäytyminen, käyttöoikeudet, tietojenkäsittely ja palvelupakettien vaatimukset ennen kuin suunnittelet minkään tuotteen varaan.

Pilotoi yhtä työnkulkua ja mittaa asiakastuloksia

Järkevä ensimmäinen pilotti on vain luku -avustaja, joka selittää varmennetut seurantatapahtumat ja siirtää epävarmat tapaukset tukipalveluun. Sitä on helpompi arvioida kuin avustajaa, joka samanaikaisesti muuttaa osoitteita, hyväksyy palautuksia ja myöntää hyvityksiä.

Luo testijoukko, joka sisältää tavallisia tilauksia ja vaikeita tapauksia: ositetut lähetykset, puuttuvat skannaukset, vanhentuneet tietueet, toimitettu mutta vastaanottamatta jäänyt -valitukset, päättyneet palautusajat ja ristiriitaiset käytäntöasiakirjat. Sisällytä yritykset käyttää toisen asiakkaan tilausta sekä viestit, jotka yrittävät ohittaa avustajan ohjeet.

• Vastausten laatu: Vastaako vastaus tarkasti haettuja lähetys- ja käytäntötietueita?
• Perusteettomat väitteet: Keksiikö se toimituspäiviä, kelpoisuutta tai suoritettuja toimintoja?
• Ratkaisun laatu: Ratkaistiinko asiakkaan ongelma vai ottiko hän uudelleen yhteyttä samasta ongelmasta?
• Eskaloinnin laatu: Siirrettiinkö epävarmat ja arkaluonteiset tapaukset hyödyllisen asiayhteyden kanssa?
• Operatiiviset kustannukset: Mikä on ratkaistun ongelman kokonaiskustannus, mukaan lukien tarkistus, integraatiot ja korjaukset?
• Asiakkaan vaivannäkö: Vähensikö työnkulku toistuvia selityksiä ja tarpeettomia vaiheita?

Älä optimoi pelkästään tukipyyntöjen vähentämistä. Harvemmat keskustelut voivat tarkoittaa parempaa itsepalvelua, mutta ne voivat myös tarkoittaa, etteivät asiakkaat päässeet avun piiriin. Laajenna pilottia vasta, kun laatu pysyy hyväksyttävänä kaikissa tapauksissa, joita järjestelmä todellisuudessa käsittelee.

Usein kysytyt kysymykset

Voiko tekoäly seurata pakettia ilman kuljetusyhtiön tietoja?

Tekoäly ei voi määrittää paketin nykyistä sijaintia vain luomalla vastauksen. Luotettava vastaus tarvitsee lähetystiedot kuljetusyhtiöltä tai muusta valtuutetusta lähteestä. Malli voi tulkita tapahtumia tai arvioida lopputulosta, mutta sen ei pitäisi esittää kumpaakaan uutena fyysisenä skannauksena.

Pitäisikö tekoälyavustajan hyväksyä palautukset automaattisesti?

Vain selkeästi määriteltyjen ja testattujen käyttöoikeuksien puitteissa. Yksiselitteiset kelpoisuussäännöt voivat käsitellä suoraviivaisia pyyntöjä, kun taas tekoäly auttaa tulkitsemaan asiakkaan kieltä. Poikkeusten, epäselvien todisteiden ja merkittävien päätösten pitäisi seurata hyväksyttyä tarkistusmenettelyä. Sovellettavia lakisääteisiä oikeuksia on myös kunnioitettava.

Mitä pienen verkkokauppatiimin pitäisi ottaa käyttöön ensin?

Aloita yhdenmukaisista tilaus- ja seurantatiedoista, saatavilla olevista käytännöistä ja luotettavista tilaan perustuvista ilmoituksista. Jos nämä perustat toimivat jo, testaa tekoälyn luomia tukiluonnoksia tai vain luku -seurantaselityksiä ennen itsenäisten toimintojen käyttöönottoa.

Kuinka paljon asiakastietoja tekoälytyönkulun pitäisi saada?

Vain tehtävään tarvittavat tiedot. Tarkista käyttöoikeudet, säilytys, lokitus, palveluntarjoajan ehdot ja sovellettavat tietosuojavelvoitteet. Vältä täydellisten asiakasprofiilien tai maksutietojen lähettämistä, jos rajattu tilausviite ja lähetyksen tila riittävät.

Mikä on vahvin merkki siitä, että toteutus toimii?

Asiakkaat saavat tarkkoja vastauksia ja asianmukaisia seuraavia vaiheita pienemmällä vaivalla, samalla kun toistuvat yhteydenotot ja korjaustyö eivät lisäänny. Nopeammat vastaukset ovat hyödyllisiä, mutta ne eivät korvaa oikeaa ratkaisua.

Lähteet

• NIST: AI Risk Management Framework — viite tekoälyn hallinnon, arvioinnin ja riskienhallinnan järjestämiseen.
• 17TRACK tracking — viite kuluttajien lähetyshakuun.
• 17TRACK Shopify -sovelluslistaus — viite kauppiaille suunnatun seurantatuotteen arviointiin.
• 17TRACK Tracking API ja virallinen API-dokumentaatio — viitteet seuranta-integraation arviointiin.
• 17RETURNS-tuotesivu — viite palautustenhallintatuotteen arviointiin.