Ko je zahtevek za podporo hkrati transakcija
Vprašanja trgovcev se skoraj vedno nanašajo na določeno transakcijo, izplačilo ali račun. V splošnem centru za podporo, ki deluje zunaj plačilne plošče, se zahtevek začne kot prazen pogovor, agent pa mora med dvema sistemoma kopirati referenčne številke transakcij, ID-je trgovcev in datume, še preden lahko sploh pogleda, kaj trgovec sprašuje.
Odpiranje zahtevka tam, kjer zapis že obstaja
Trgovec lahko namesto tega zahtevek odpre neposredno iz transakcije, računa ali denarnice, ki si jo ogleduje, tako da referenca potuje skupaj s pogovorom, namesto da bi jo bilo treba vanj kopirati. Operater, ki odgovarja na zahtevek, gleda dejanski zapis, ne posnetka zaslona ali kopiranega identifikatorja.
Ena čakalna vrsta, enake pravice dostopa
Upravitelji najemnikov zahtevke za podporo obravnavajo znotraj lastne plošče, pod enakim nadzorom dostopa na podlagi vlog, ki velja za preostali del njihovega dostopa. Osebje za podporo ne potrebuje širših pravic samo zato, da odgovori na vprašanje, prav tako ni drugega prijavnega sistema, ločene nastavitve SSO ali drugega mesta, kjer bi bili shranjeni osebni podatki trgovca.
Skupna shramba namesto drugega datotečnega sistema
Priloge, kot so potrdila in dokazila, uporabljajo isto shrambo dokumentov in iste poti za prenos kot dokazila pri spornih primerih. Ničesar ni treba podvajati v drug sistem in nič se ne izgubi med prilogo in zapisom, ki ga je bila namenjena podpreti.
Kaj to spremeni v vsakdanjem delu
Ker so zahtevki omejeni na posameznega najemnika in se vrstijo znotraj platforme, je poročanje o odzivnih časih lastnost platforme same, ne nekaj, kar se naknadno sestavi iz dveh sistemov. In ker se zahtevki odpirajo iz konteksta, odpade še ena kategorija napak: napačna referenca transakcije, kopirana v napačen pogovor.
Neobvezna plast in kam sodijo sporni primeri
Poleg nabiralnika za podporo lahko ločen modul razvršča prihajajoče zahtevke po prioriteti in pripravi predloge odgovorov na podlagi istega konteksta transakcije in trgovca, ki ga operater že vidi – operater še vedno ureja in pošilja sam, trgovcu pa nič ne gre samodejno. To deluje vzporedno z lastnim potekom spornih primerov na platformi, kjer lahko trgovec sproži spor glede plačila ali izplačila, navede razlog in priloži do pet dokazil, upravitelj pa ga reši tako, da se stanja samodejno povrnejo in ponovno knjižijo – s tem pogovor za podporo in spor, do katerega lahko pripelje, ostajata na istem mestu.
