Korisnička podrška i zahtjevi

1. Pitanje na koje je ova značajka najprije morala odgovoriti

Koji zahtjev?

Izrada zahtjeva za svaku identificiranu sesiju bila bi neželjena pošta: tim podrške nalazio bi slučajeve koje nitko nije otvorio. Dodavanje bilješke svakom zahtjevu koji je osoba ikad poslala također bi bilo neželjeno, samo sporije.

Zato: interna bilješka uz najnoviji OTVORENI zahtjev pošiljatelja. Ako nema otvorenog zahtjeva, ništa se ne događa. Tako nikad ne otvaramo slučaj koji kupac nije pokrenuo, a agent pronalazi snimku točno ondje gdje već traži.

Interno, nikad javno. Poveznica vodi u MousePlayer. Vaš je kupac ne bi trebao vidjeti, a ionako je ne bi mogao otvoriti.

2. Zendesk Support i Freshdesk

Oba su podržana i isti posao rješavaju drukčije. Ne morate se time baviti, ali to objašnjava zašto obrazac traži malo različite podatke.

	Zendesk Support	Freshdesk
Poddomena	`acme` iz acme.zendesk.com	`acme` iz acme.freshdesk.com
E-pošta agenta	potrebna – Zendesk se prijavljuje kao `email/token`	nije potrebna, ostavite prazno
API token	Administratorski centar → Aplikacije i integracije → API-ji	Postavke vašeg profila
Bilješka postaje	interni komentar uz zahtjev	privatna bilješka uz zahtjev

Zalijepite cijeli URL u polje poddomene ako vam je lakše – skraćujemo ga na potrebni dio pa https://acme.zendesk.com/agent/tickets/1 postaje acme.

3. Kada se pokreće

U trenutku identifikacije sesije – kada web-mjesto pozove MousePlayer.setUserId(), kada naš analitički most pročita jedinstveni ID ili kada vaš poslužitelj pozove krajnju točku za identifikaciju.

Samo s adresom e-pošte

Zahtjev pripada pošiljatelju, a sustav podrške poznaje ga po e-pošti. Broj ugovora ondje ne vodi nikamo pa se ništa ne šalje.

Samo za otvorene zahtjeve

Riješeni i zatvoreni zahtjevi preskaču se. Bilješka uz slučaj koji više nitko ne gleda nikome ne pomaže i bez razloga bi vratila zatvoreni zahtjev pred agente.

Ako pošiljatelj nema otvoreni zahtjev, to se računa kao dovršeno, a ne neuspjelo – to je uobičajen slučaj i ponovni pokušaj ništa ne bi promijenio.

4. Što agent vidi

Jedna interna bilješka: MousePlayer: snimka sesije od <email> nakon koje slijedi poveznica. Jednim klikom gledaju što je osoba stvarno radila, odmah pokraj onoga što je o tome napisala.

Gdje ovo opravdava svoju svrhu

Zahtjevi „Ne radi“. Snimka obično u dvadeset sekundi pokaže ono što tri razmjene e-pošte ne bi.
Koraci za reprodukciju koje nitko ne može ponoviti. Više ih ne trebate – imate sesiju.
Bijesni klikovi i klikovi bez reakcije koje kupac nikad ne spomene jer pretpostavlja da proizvod tako radi.

Token nikad ne napušta naš poslužitelj

Pohranjuje se šifriran algoritmom AES-256-GCM, nakon spremanja više se ne prikazuje i namjerno se izostavlja iz internog reda sa zadatkom.

5. Help Scout, Front i Gorgias

Još tri sustava podrške. Sva tri dodaju internu bilješku uz otvoreni razgovor, svaki na drukčiji način.

	Navodite	Poddomena
Help Scout	ID i tajnu klijenta interne aplikacije	nije potrebna
Front	API token i ID člana tima	nije potrebna
Gorgias	e-poštu agenta i API ključ	potrebna

Help Scout najprije razmjenjuje vjerodajnice

Ne prihvaća tajnu klijenta izravno. Most je najprije zamjenjuje za kratkotrajni pristupni token – tok vjerodajnica klijenta, namijenjen integraciji koja djeluje za sebe, a ne za korisnika. Token je tijekom valjanosti u memoriji; tajna ostaje u bazi podataka.

Komentari u Frontu trebaju autora

Komentar u Frontu pojavljuje se u ime člana tima i API ga zahtijeva. Ovdje ga sadrži polje označeno za agenta – nije prijava, nego ID pod čijim se imenom bilješka prikazuje.

Gorgias zahtijeva dva upita umjesto jednog

Njegov popis zahtjeva filtrira prema customer_id i ničemu drugome – nema filtra e-pošte. Zato most najprije traži kupca, a zatim njegove zahtjeve. Ne može filtrirati ni prema statusu pa se otvoreni zahtjev odabire na našoj strani, jednako kao već kod Freshdeska.

Kako možemo pomoći?