Labākā palīdzības dienesta programmatūra: deviņas platformas salīdzinātas

Palīdzības dienesta programmatūra pārvērš pasta kastīti par darbojošos operāciju. Pieprasījumam ir īpašnieks, statuss, taimeris un vieta rindā, un komandai vairs nav jāpaļaujas uz to, ka kāds kaut ko atceras.

Tālāk pēc vieniem un tiem pašiem kritērijiem aplūkotas deviņas platformas. Konkurentu cenas nav norādītas, jo tās mainās starp plāniem ātrāk, nekā lapu var atjaunināt.

Biļetes uzbūve

Katra šīs kategorijas platforma modelē vienu un to pašu objektu, un atšķirības meklējamas tajā, kas to ieskauj.

Biļetei ir īpašnieks, statuss, prioritāte un pieprasītājs. Šie četri lauki atšķir palīdzības dienestu no pasta kastītes, jo katrs no tiem atbild uz jautājumu, uz kuru e-pasts nespēj atbildēt: kam tā ir, kur tā atrodas, cik steidzama tā ir un kā problēmu tā risina.

Nākamais slānis ir taimeris. SLA mērķis pārvērš steidzamību no viedokļa par mērāmu lielumu, un eskalācija liek novecojošai biļetei kļūt par kāda cita problēmu, pirms tā kļūst par klienta sūdzību.

Nākamais slānis ir konteksts. Biļete, kas zina tikai savu paša pavedienu, ir darba vienība. Biļete, kas piesaistīta klienta ierakstam, zina pēdējos trīs pieprasījumus, telefona zvanu un konta līmeni, un tāpēc uz to atbild savādāk.

Kopīga iesūtne vai biļešu sistēma

Šo kategoriju sadala divas filozofijas, un nepareizas izvēle rada vairāk berzes nekā nepareiza pakalpojumu sniedzēja izvēle.

Kopīgas iesūtnes programmatūra saglabā e-pasta formu. Nav biļešu numuru priekšmeta laukā, nav statusa terminoloģijas klienta priekšā, un atbildes izklausās tā, it kā tās rakstījis cilvēks. Tas piemērots mazākam apjomam un attiecībām, kurās formalitāte šķistu nevietā.

Biļešu sistēma padara darba objektu skaidri redzamu. Aģentam redzami statusi, rindas, SLA politikas un masveida darbības, un pārskati ir bagātīgāki, jo tiek reģistrēta katra statusa maiņa.

Izvēli nosaka apjoms. Ja apjoms mēnesī ir aptuveni zem pieci simti pieprasījumu, kopīga iesūtne parasti šķiet ērtāka; virs šī sliekšņa statusu trūkums sāk izmaksāt vairāk, nekā formalitāte būtu ietaupījusi.

Dažas platformas apvieno abas pieejas, virspusē saglabājot iesūtnes formu, bet apakšā - biļetes struktūru. Tieši šādu kārtību izmanto RolChat.

Deviņas platformas īsumā

RolChat

RolChat virspusē saglabā iesūtnes formu, bet apakšā - biļešu struktūru. Jebkura ziņa kļūst par izsekotu vienību ar īpašnieku, prioritāti, SLA mērķi un eskalācijas ceļu, un pavediens turpinās tajā pašā vietā, nevis pārvēršas lietas numurā.

Šo iesūtni papildina vienpadsmit kanāli, tostarp mākoņa telefonsistēma ar IVR, ierakstīšanu un transkripciju, tāpēc zvans un e-pasts par vienu un to pašu pieprasījumu paliek vienā ierakstā.

CRM ir dabisks, nevis integrēts: uzņēmumi, kontaktpersonas, darījumi un pipelīni atrodas vienā darbvietā, un tas ļauj SLA atšķirties pēc konta līmeņa bez sinhronizācijas darba.

AI darbojas ar jūsu norādītu atslēgu, izmantojot 62 teksta modeļus no septiņiem pakalpojumu sniedzējiem. Cenas noteiktas par uzņēmumu, nevis par vietu: $19, $49 un $99 mēnesī, Enterprise plānam cena tiek noteikta individuāli.

Piemērots: komandām, kas vēlas biļešu disciplīnu bez biļešu formalitātes, kā arī balss un CRM vienā abonementā.

Zendesk

Zendesk ir šīs kategorijas atsauces risinājums. Trigeri, automatizācijas, makro, skati un SLA politikas ir dziļākas nekā jebkur citur šajā sarakstā, un pārskatu slānis tam atbilst.

Aģenta darbvieta izveidota lielam apjomam, un plašs tirgus vietu papildina to, kas trūkst pamatproduktā.

Izmaksas ir konfigurācija. Ieviešana mērāma nedēļās, un pārdošanas puse vēsturiski bijusi atsevišķs produkts.

Piemērots: lielam biļešu apjomam ar dedicētu administratoru. Pārbaudiet plānus Zendesk vietnē.

Freshdesk

Freshdesk apvieno nobriedušu biļešu apstrādi ar spēcīgu automatizāciju un vienkāršāku iestatīšanu nekā tās galvenajam konkurentam, tāpēc tā parādās daudzos vidējā tirgus segmenta sarakstos.

Tās Freshworks radniecīgie produkti paplašina funkcionalitāti uz tērzēšanu, telefoniju, CRM un analītiku, katram ar savu līmeņu skalu.

Freddy nodrošina AI slāni visā komplektā saskaņā ar pakalpojumu sniedzēja publicētajiem noteikumiem.

Piemērots: biļetēs balstītam darbam lielā apjomā, īpaši kopā ar citiem Freshworks produktiem. Pārbaudiet plānus Freshdesk vietnē.

HubSpot Service Hub

Service Hub atrodas CRM komplekta iekšienē, tāpēc klienta ieraksts patiešām ir kopīgs ar mārketingu un pārdošanu jau no pirmās dienas.

Tas ir tā spēcīgākais arguments un galvenais ierobežojums: vērtība ir atkarīga no plašākas platformas ieviešanas, un atbalsta iespējas ir sadalītas pa līmeņiem.

Uzņēmumiem, kas jau izmanto CRM, tas ir vienkārši papildinošs risinājums. Visiem pārējiem tas ir lielāks lēmums nekā palīdzības dienesta iegāde vien.

Piemērots: komandām, kas jau izmanto attiecīgo CRM. Pārbaudiet līmeņu saturu HubSpot vietnē.

Help Scout

Help Scout ir vislabāk zināmā kopīgā iesūtne šajā sarakstā, veidota ap e-pastu ar pievienotu palīdzības centru un apzināti nesteidzīgu aģenta skatu.

Tā pilnībā izvairās no biļešu numuru formalitātes, kas piemērots komandām, kuru atbildēm nevajadzētu izklausīties tā, it kā tās ģenerējusi sistēma.

Kanālu pārklājums ir šaurāks nekā universālajām platformām, un telefonija nav produkta sastāvdaļa.

Piemērots: e-pastā balstītam atbalstam, kur tonis ir svarīgāks par rindas mehāniku. Pārbaudiet plānus Help Scout vietnē.

Front

Front ir sadarbības iesūtne: iekšējie komentāri, kopīgi melnraksti un uzdevumi atrodas blakus ziņai, nevis atsevišķā pavedienā.

Šī forma piemērota B2B apkalpošanai, kur kontiem ir nosaukti īpašnieki un kur atbilde tiek apspriesta pirms nosūtīšanas.

Biļešu formalitāte un telefonija ir vieglāka nekā iepriekš minētajās biļešu sistēmās, un tas ir iemesls, kāpēc, pieaugot apjomam, rodas interese par Front alternatīvām.

Piemērots: B2B komandām, kas kopā izstrādā atbildes nosauktiem kontiem. Pārbaudiet plānus Front vietnē.

Zoho Desk

Zoho Desk ir kompetenta biļešu apstrāde ļoti lielā produktu saimē, un tās cenas jau ilgi ir bijušas vienas no agresīvākajām šajā kategorijā.

Organizācijām, kas jau izmanto citas Zoho lietotnes, kopīgais datu modelis ir īsts ieguvums.

Izmantojot atsevišķi, tā prasa vairāk konfigurācijas, nekā liktu domāt tās cenu diapazons.

Piemērots: uzņēmumiem, kas jau darbojas Zoho ekosistēmā. Pārbaudiet plānus Zoho vietnē.

Gorgias

Gorgias ir palīdzības dienests, kas izveidots tieši tiešsaistes veikaliem, ar pasūtījumu datiem, atmaksām un abonementa darbībām, kas pieejamas tieši biļetē.

Veikalam, kas visu dienu apstrādā atgriešanas un piegādes jautājumus, šī specializācija novērš vairāk klikšķu, nekā to spēj jebkura universāla platforma.

Tās uzskaite notiek pēc biļešu apjoma, nevis pēc aģentu skaita, kas atšķiras no visa pārējā šajā sarakstā.

Piemērots: e-komercijas atbalstam, kas cieši saistīts ar veikala platformu. Pārbaudiet plānus Gorgias vietnē.

Groove

Groove ir vienkārša kopīga iesūtne mazām komandām, ar zināšanu bāzi un pārskatiem, kas nosedz pamatlietas bez konfigurācijas projekta.

Tā apzināti ir pieticīga savā apjomā, un tieši to daļa komandu vēlas no pirmā palīdzības dienesta.

Kanālu daudzveidību un automatizācijas dziļumu ierobežo tā pati izvēle.

Piemērots: mazām komandām, kas vēlas pirmo palīdzības dienestu bez mācīšanās līknes. Pārbaudiet plānus Groove vietnē.

SLA, prioritātes un eskalācija

SLA ir solījums ar pievienotu taimeri, un tieši taimeris ir daļa, kurā lielākā daļa ieviešanu kļūdās.

Mērķiem jāatšķiras pēc rindas un konta līmeņa, jo norēķinu jautājums un dīkstāve nav pelnījuši vienu un to pašu atbildes laika logu, un galvenajam kontam parasti ir līgums, kas to nosaka.

Taimerim jāņem vērā darba laiks un brīvdienas, citādi katra nedēļas nogale rada nepatiesus pārkāpumus, un pārskats kļūst par troksni, ko neviens nelasa.

Eskalācija padara mērķi reālu. Noteikums, kas paceļ novecojošu biļeti pie vadītāja, pirms mērķis ir nokavēts, pārvērš SLA no pārskata artefakta par darbības kontroles instrumentu.

Atkārtotas atvēršanas rādītājs ir jāskata blakus atrisināšanas laikam. Augsts atrisināto biļešu skaits kopā ar augstu atkārtotas atvēršanas rādītāju nozīmē, ka biļetes tiek slēgtas, nevis atrisinātas.

Automatizācija, kas iztur reorganizāciju

Automatizāciju ir viegli izveidot un grūti uzturēt. Lielākā daļa palīdzības dienestu uzkrāj noteikumus, ko neviens neatceras esam uzrakstījis, un šis krājums kļūst par iemeslu neko nemainīt.

Uzturamu noteikumu kopu nosaka trīs īpašības. Noteikumiem jābūt lasāmiem kā teikumam, nevis atšifrējamiem no režģa. Tiem jābūt individuāli ieslēdzamiem un izslēdzamiem, lai sliktu izmaiņu varētu atsaukt, neaiztiekot pārējo. Un tiem jābūt rediģējamiem administratoram, nevis izstrādātājam.

Darbības joma ir tikpat svarīga kā sintakse. Noteikumu dzinējs, kas aptver biļetes, tērzēšanu, CRM un balsi, vienā noteikumā var apzīmēt sarunu, piešķirt īpašnieku, sākt taimeri un atvērt darījumu; dzinējam, kas darbojas vienā modulī, katram solim ir nepieciešama integrācija.

Kapacitātes ierobežojumiem un darba laikam jābūt tajā pašā dzinējā, jo maršrutēšana, kas ignorē to, kurš patiešām ir pieejams, ir maršrutēšana, kas rada rindas.

AI palīdzības dienestā

AI palīdzības dienesta programmatūra aptver trīs atšķirīgus uzdevumus, un pakalpojumu sniedzēji visus trīs apzīmē ar vienu un to pašu vārdu.

Šķirošana ir vismazāk redzamā un bieži vien vērtīgākā funkcija: klasificēšana, marķēšana, prioritātes noteikšana un maršrutēšana, aģentam vēl nelasot ziņu.

Melnrakstu veidošana ir tā, ko aģenti pamana. Modelis raksta atbildi, balstoties uz apstiprinātu saturu, un aģents pirms nosūtīšanas to rediģē, kas saīsina apstrādes laiku, neriskējot ar nepareizu atbildi.

Autonoma atbildēšana ir trešā, un tai nepieciešams visvairāk satura pamatā. Asistents, kas balstīts uz sešiem rakstiem, atbild kā rīks, kas izlasījis sešus rakstus.

Komerciālais jautājums ir atsevišķi no šiem trim. Norēķini par atrisinātu biļeti sasaista rēķinu ar to, cik labi darbojas automatizācija; savas modeļa atslēgas pieslēgšana saglabā secinājumu izmaksas vairumtirdzniecības līmenī un atstāj modeļa izvēli pircēja ziņā.

Risinājumi mazajam biznesam

Palīdzības dienesta programmatūra mazajam biznesam nes trīs neizteiktas prasības: zemu sākuma cenu, iestatīšanu, kas nav projekts, un iespēju augt bez atkārtotas pārcelšanās.

Pirmās divas prasības tiek plaši izpildītas. Trešā ir vieta, kur patiešām pieņem lēmumu, jo migrācija pēc gada izmaksā vairāk, nekā jebkad ietaupīja licences cenu starpība.

Praktiskais tests ir, vai platformā jau ir tas, kas būs nepieciešams pēc divpadsmit mēnešiem. Zvani, konta ieraksts, SLA mērķi pēc līmeņa un otra valoda ir tie četri elementi, kas visbiežāk parādās ātrāk, nekā gaidīts.

Vienkārša palīdzības dienesta programmatūra ir reāla kategorija un pamatota izvēle, ja vien vienkāršība nozīmē mazāk iestatījumu, nevis mazāk iespēju.

Bezmaksas plāni un vēlākās izmaksas

Bezmaksas palīdzības dienesta programmatūra pastāv un darbojas, ar ierobežojumiem, kas ir līdzīgi visiem pakalpojumu sniedzējiem.

Vispirms tiek ierobežoti aģentu skaits, tad vēstures glabāšanas ilgums un visbeidzot integrācijas. Ierobežojumi ir noteikti tā, ka augoša komanda tos sasniedz aptuveni ceturksni pēc pievienošanās.

Slēptās izmaksas reti ir jaunināšanas cena. Tā ir tas, ka automatizācija, saglabātās atbildes un pārskati, kas veidoti bezmaksas periodā, var neizdzīvot pāreju pie cita pakalpojumu sniedzēja, kad jaunināšana šķiet neizdevīga.

RolChat nav mūžīgi bezmaksas plāna. 30 dienu izmēģinājums atbloķē visas funkcijas un pieprasa karti; pirmā maksa tiek iekasēta 31. dienā ar atgādinājumu trīs dienas iepriekš.

Pašapkalpošanās un biļešu novirzīšana

Novirzīšana ir vienīgais šīs kategorijas rīks, kas darbu nevis pārceļ, bet novērš pilnībā.

Palīdzības centrs jūsu pašu domēnā saglabā gan trafiku, gan meklēšanas vērtību; centrs pakalpojumu sniedzēja apakšdomēnā veido kāda cita vērtību. Šo izvēli ir grūti mainīt, kad raksti jau indeksēti.

Rakstu analītika un tukšo meklējumu pārskati pārvērš satura uzkrājumu par rindas virzītu sarakstu. Jautājumi, kas atkārtoti parādās bez atbilstoša raksta, ir nākamie, kas jāraksta.

Asistenta balstīšana uz to pašu apstiprināto saturu nodrošina, ka tērzēšanas atbilde un raksts sakrīt. Divas atbildes uz vienu jautājumu ir sliktāk nekā viena lēna atbilde.

Pārskati, kas maina personāla plānošanu

Lielākā daļa palīdzības dienesta pārskatu tiek lasīti reizi ceturksnī un neko nemaina. Pārskati, kas patiešām maina lēmumus, ir šaurāki, nekā liek domāt informācijas paneļi.

Apjoms pēc diennakts stundas nosaka maiņu grafikus. Apjoms pēc iemesla nosaka, ko automatizēt un ko dokumentēt. Atkārtotas atvēršanas rādītājs nosaka, vai kvalitāte tiek uzturēta.

Slodze pa aģentiem ir mazāk svarīga nekā slodzes atšķirība starp aģentiem: vienmērīga rinda ar garu vidējo laiku ir personāla problēma, nevienmērīga - maršrutēšanas problēma, un risinājums atšķiras.

Ja balss ir dabiska funkcija, zvanu metrikai jābūt tajā pašā pārskatā, kur rakstiskajai. Šo datu sadalīšana divās konsolēs ir veids, kā komandas beidz optimizēt vienu kanālu uz cita rēķina.

E-pasta piegādājamība un adrese, no kuras atbildat

E-pasts joprojām ir lielākais kanāls lielākajā daļā palīdzības dienestu, un vismazāk pārbaudītā iestatīšanas daļa ir tas, no kurienes nāk atbildes.

Sūtīšana no sava domēna prasa DNS ierakstus, kurus norādīs platforma, un to izlaišana ir iemesls, kāpēc atbildes nonāk surogātpastā trīs nedēļas pēc palaišanas, nevis pirmajā dienā.

Pavedienu veidošana ir otra detaļa. Platforma, kas pārtrauc atbilžu ķēdi, izveido dublētas biļetes vienai sarunai, kas pārspīlē apjoma pārskatus un kaitina klientu.

Pārsūtīšanas noteikumiem no vecās pasta kastītes jābūt pagaidu risinājumam. Ja tos atstāj uz nenoteiktu laiku, divas sistēmas domā, ka tām pieder viens un tas pats pieprasījums.

Migrācija un piesaiste vienam piegādātājam

Katru šeit minēto platformu ir viegli sākt izmantot. Tās atšķiras ar to, cik viegli tās ir pamest, un šai atšķirībai jābūt daļai no cenas jau pirkuma brīdī.

Pārbaudiet, vai biļešu vēsture eksportējas izmantojamā formātā, vai palīdzības centra raksti saglabā savas URL adreses caur pāradresācijām un vai kontaktpersonas paliek ar neskartiem pielāgotiem laukiem.

Automatizācija starp platformām nepārceļas, jo modeļi atšķiras. Teksts makro un saglabātajās atbildēs gan pārceļas, un tā atjaunošana parasti ir ātrāka nekā oriģinālā veidošana.

Divas nedēļas paralēlas darbības izmaksā vienu papildu licences periodu un novērš lielāko daļu risku. Tā joprojām ir lētākā apdrošināšana šajā kategorijā.

Lomas, atļaujas un darbību žurnāls

Palīdzības dienestā tiek uzglabāts vairāk personas datu nekā lielākajā daļā uzņēmuma sistēmu, un ar to saistītās kontroles šajā sarakstā ievērojami atšķiras.

Lomām jānosaka, kuras rindas persona atver, kurus laukus tā drīkst rediģēt, kurus pārskatus tā lasa un kurus eksportus tā var palaist. Lasīšanas piekļuve visam ir noklusējums vairāk produktos, nekā vajadzētu.

Darbību žurnāls fiksē, kas darīts un kurš to darījis. Tas ir tas, ko prasa auditors, un tas, ko neviens nepārbauda, kamēr netiek jautāts.

Vairāku zīmolu un baltā etiķetes iestatījumi ir svarīgi aģentūrām un grupām: atsevišķi zīmoli vienā kontā ar vadītāju, kurš joprojām redz tos visus.

Piekrišanas apstrāde pieder blakus dienestam, nevis atsevišķam pakalpojumu sniedzējam. RolChat piedāvā sīkdatņu joslu, sīkdatņu skeneri, piekrišanas žurnālu un DSAR apstrādi kā papildinājumu par $5 par vietni.

Daudzvalodu dienesti

Otrs tirgus ir visbiežākais iemesls, kāpēc palīdzības dienesta izvēle tiek pārskatīta divu gadu laikā.

Saskarnes pārklājums ir pirmā prasība, un tas nav tas pats, kas satura pārklājums. RolChat piedāvā 40 saskarnes valodas, un maršrutēšana var novirzīt pieprasījumu tam, kurš prot attiecīgo valodu, nevis tam, kurš ir brīvs.

Tulkošana sarunas iekšienē maina personāla plānošanas jautājumu no pieņemšanas darbā pēc valodas uz maršrutēšanu pēc valodas, kas ir atšķirība starp tirgus atvēršanu un tā atlikšanu.

Palīdzības centra rakstiem jāglabā valodu varianti vienā URL struktūrā, nevis kā atsevišķām vietnēm, citādi otrais tirgus kļūst par migrāciju, nevis tulkošanu.

Integrācijas un plašākais rīku kopums

Palīdzības dienests darbojas blakus CRM, norēķinu sistēmai, veikala platformai un kalendāram, un tas, kā tas ar tiem savienojas, nosaka, cik daudz aģenti kopē datus manuāli.

Divi jautājumi atšķir īstu integrāciju no vienkārša ieraksta. Vai tā raksta atpakaļ, lai aģenta darbība atjauninātu otru sistēmu, nevis tikai nolasītu no tās. Un vai tā izdzīvo shēmas izmaiņas jebkurā pusē bez izstrādātāja iesaistes.

Savienotāju skaitīšana ir vājš spēju rādītājs. Platformai ar dabisku CRM, biļetēm un balsi to nepieciešams mazāk nekā tai, kurai visas trīs jāaizņemas, un katra aizņemtā sistēma ir vieta, kur klienta ieraksts var novirzīties.

Ja savienotāja nav, API un webhooks, kas abos virzienos pārnes biļetes, kontaktpersonas un notikumus, ir rezerves risinājums, kas jāpārbauda izmēģinājuma laikā.

Biežāk uzdotie jautājumi

Ruslan Nazarov

SEO vadītājs uzņēmumā RolChat

Raksta par klientu atbalsta darbu, tiešsaistes čatu, AI atbalstītu apkalpošanu un rīkiem, kas nodrošina labu klientu pieredzi.

LinkedIn