Geriausia pagalbos tarnybos programinė įranga: devynios palygintos platformos

Pagalbos tarnybos programinė įranga paverčia pašto dėžutę veikiančia operacija. Užklausa gauna savininką, būseną, laikmatį ir vietą eilėje, o komanda nustoja tikėtis, kad kažkas prisimins.

Toliau devynios platformos apžvelgiamos pagal tuos pačius kriterijus. Konkurentų kainos nepateikiamos, nes jos tarp planų keičiasi greičiau, nei galima atnaujinti puslapį.

Bilieto anatomija

Kiekviena šios kategorijos platforma modeliuoja tą patį objektą, o skirtumai slypi tame, kas jį supa.

Bilietas turi savininką, būseną, prioritetą ir prašytoją. Šie keturi laukai skiria pagalbos tarnybą nuo pašto dėžutės, nes kiekvienas jų atsako į klausimą, į kurį el. paštas negali: kas tuo užsiima, kur tai yra, koks tai skubumas ir kieno problemą tai sprendžia.

Kitas sluoksnis - laikmatis. SLA tikslas paverčia skubumą iš nuomonės į matavimą, o eskalavimas paverčia senstantį bilietą kažkieno problema dar prieš jam tampant kliento skundu.

Sekantis sluoksnis - kontekstas. Bilietas, kuris žino tik savo giją, yra darbo vienetas. Bilietas, prijungtas prie kliento įrašo, žino paskutines tris užklausas, skambutį ir paskyros lygį, ir dėl to į jį atsakoma kitaip.

Bendra pašto dėžutė ar bilietų sistema

Šioje kategorijoje susiduria dvi filosofijos, ir neteisingo pasirinkimo padariniai kelia daugiau trinties nei neteisingo tiekėjo pasirinkimas.

Bendros pašto dėžutės programinė įranga išlaiko el. pašto formą. Jokių bilietų numerių temos eilutėje, jokio būsenų žodyno prieš klientą, o atsakymai skamba taip, tarsi juos parašė žmogus. Ji tinka mažesniam kiekiui ir santykiams, kur formalumas atrodytų netinkamas.

Bilietų sistema padaro darbo objektą aiškų. Agentui matomos būsenos, eilės, SLA politikos ir masiniai veiksmai, o ataskaitos yra išsamesnės, nes kiekvienas būsenos pasikeitimas užfiksuojamas.

Sprendžia apimtis. Iki maždaug penkių šimtų užklausų per mėnesį bendra pašto dėžutė paprastai atrodo geriau; virš jos formalumo trūkumas pradeda kainuoti daugiau, nei sutaupytų formalumas.

Kai kurios platformos daro abu dalykus - išlaiko pašto dėžutės formą paviršiuje ir bilietų struktūrą apačioje. Toks yra RolChat naudojamas sprendimas.

Devynios platformos vienu žvilgsniu

RolChat

RolChat išlaiko pašto dėžutės formą paviršiuje, o bilietų struktūrą apačioje. Bet kokia žinutė tampa sekamu elementu su savininku, prioritetu, SLA tikslu ir eskalavimo keliu, o gija tęsiasi toje pačioje vietoje, o ne virsta bylos numeriu.

Šią pašto dėžutę maitina vienuolika kanalų, įskaitant debesų telefonijos sistemą su IVR, įrašymu ir transkribavimu, tad skambutis ir el. laiškas apie tą pačią užklausą atsiduria viename įraše.

CRM yra integruotas natūraliai, o ne prijungtas: įmonės, kontaktai, sandoriai ir pardavimo kanalai gyvena toje pačioje darbo aplinkoje, ir būtent tai leidžia SLA skirtis pagal paskyros lygį be sinchronizavimo darbo.

DI veikia naudojant jūsų pačių pateiktą raktą, apimant 62 teksto modelius iš septynių tiekėjų. Kainodara taikoma įmonei, o ne vietai: 19, 49 ir 99 USD per mėnesį, Enterprise kaina nustatoma individualiai.

Geriausiai tinka: komandoms, norinčioms bilietų drausmės be bilietų formalumo, taip pat balso ir CRM toje pačioje prenumeratoje.

Zendesk

Zendesk yra šios kategorijos etaloninis sprendimas. Trigeriai, automatizacijos, makrokomandos, rodiniai ir SLA politikos yra išsamesni nei bet kur kitur šiame sąraše, o ataskaitų sluoksnis tam prilygsta.

Agento darbo aplinka sukurta dideliems kiekiams, o didelė rinkos vieta apima viską, ko netaiko pagrindinis produktas.

Kaina - konfigūracija. Diegimas trunka savaites, o pardavimų sritis istoriškai buvo atskiras produktas.

Geriausiai tinka: dideliam bilietų kiekiui su atskiru administratoriumi. Planus patikrinkite Zendesk svetainėje.

Freshdesk

Freshdesk sujungia brandžius bilietus su stipria automatizacija ir lengvesniu diegimu nei pagrindinis konkurentas, todėl jis patenka į tiek daug vidutinės rinkos trumpųjų sąrašų.

Jo Freshworks produktai plečiasi į pokalbius, telefoniją, CRM ir analitiką, kiekvienas su savo pakopų sistema.

Freddy suteikia DI sluoksnį visam paketui, tiekėjo skelbiamomis sąlygomis.

Geriausiai tinka: bilietų formos darbui dideliu kiekiu, ypač kartu su kitais Freshworks produktais. Planus patikrinkite Freshdesk svetainėje.

HubSpot Service Hub

Service Hub yra CRM pakete, todėl kliento įrašas nuo pat pirmos dienos iš tiesų dalinamas su rinkodara ir pardavimais.

Tai jo stipriausias argumentas ir pagrindinis apribojimas: vertė priklauso nuo platesnės platformos naudojimo, o palaikymo galimybės paskirstytos tarp lygių.

Įmonėms, jau naudojančioms CRM, tai lengvas papildymas. Visiems kitiems tai didesnis sprendimas nei pagalbos tarnybos pirkimas.

Geriausiai tinka: komandoms, jau įsipareigojusioms naudoti aplinkinį CRM. Lygių turinį patikrinkite HubSpot svetainėje.

Help Scout

Help Scout yra geriausiai žinoma bendra pašto dėžutė šiame sąraše, sukurta aplink el. paštą su prijungtu pagalbos centru ir sąmoningai ramiu agento vaizdu.

Ji visiškai vengia bilietų numerių formalumo, kas tinka komandoms, kurių atsakymai neturėtų skambėti taip, tarsi juos sugeneravo sistema.

Kanalų aprėptis siauresnė nei visa apimančių platformų, o telefonija nėra produkto dalis.

Geriausiai tinka: el. paštu grįstam palaikymui, kur tonas svarbesnis nei eilės mechanika. Planus patikrinkite Help Scout svetainėje.

Front

Front yra bendradarbiavimo pašto dėžutė: vidiniai komentarai, bendri juodraščiai ir priskyrimai atsiduria šalia žinutės, o ne atskiroje gijoje.

Ši forma tinka B2B aptarnavimui, kur paskyros turi vardinius savininkus ir kur atsakymas aptariamas prieš jį išsiunčiant.

Bilietų formalumas ir telefonija yra lengvesni nei aukščiau minėtose bilietų sistemose, ir būtent tai skatina domėjimąsi Front alternatyvomis, kai kiekis auga.

Geriausiai tinka: B2B komandoms, kurios kartu rengia atsakymus vardinėms paskyroms. Planus patikrinkite Front svetainėje.

Zoho Desk

Zoho Desk yra kompetentingi bilietai labai didelėje produktų šeimoje, o jo kainodara jau seniai yra viena iš agresyviausių kategorijoje.

Organizacijoms, jau naudojančioms kitas Zoho programas, bendras duomenų modelis yra tikras pranašumas.

Naudojamas atskirai, jis reikalauja daugiau konfigūracijos, nei rodo jo kainų juosta.

Geriausiai tinka: įmonėms, jau esančioms Zoho ekosistemoje. Planus patikrinkite Zoho svetainėje.

Gorgias

Gorgias yra pagalbos tarnyba, sukurta būtent internetinėms parduotuvėms, kurioje bilieto viduje prieinami užsakymo duomenys, grąžinimai ir prenumeratos veiksmai.

Parduotuvei, kuri visą dieną tvarko grąžinimus ir pristatymo klausimus, ši specializacija pašalina daugiau paspaudimų, nei sugeba bet kuri bendra platforma.

Jo matavimas vyksta pagal bilietų kiekį, o ne pagal agentus, o tai skiriasi nuo visko kito šiame sąraše.

Geriausiai tinka: el. prekybos palaikymui, glaudžiai susietam su parduotuvės platforma. Planus patikrinkite Gorgias svetainėje.

Groove

Groove yra paprasta bendra pašto dėžutė mažoms komandoms, su žinių baze ir ataskaitomis, kurios apima pagrindinius dalykus be konfigūracijos projekto.

Ji sąmoningai neturi didelių ambicijų apimties atžvilgiu, ir būtent to kai kurios komandos nori iš pirmos pagalbos tarnybos.

Kanalų platumą ir automatizacijos gylį riboja tas pats pasirinkimas.

Geriausiai tinka: mažoms komandoms, norinčioms pirmos pagalbos tarnybos be mokymosi kreivės. Planus patikrinkite Groove svetainėje.

SLA, prioritetai ir eskalavimas

SLA yra pažadas su prijungtu laikmačiu, ir būtent laikmatis yra dalis, kurią dažniausiai neteisingai įgyvendina.

Tikslai turėtų skirtis pagal eilę ir paskyros lygį, nes atsiskaitymo klausimas ir gedimas nenusipelno to paties atsakymo lango, o pagrindinė paskyra dažniausiai turi sutartį, kuri tai numato.

Laikmatis turi paisyti darbo valandų ir švenčių dienų, kitaip kiekvienas savaitgalis sukuria klaidingus pažeidimus, o ataskaita tampa triukšmu, kurio niekas neskaito.

Eskalavimas paverčia tikslą realiu. Taisyklė, kuri perkelia senstantį bilietą prižiūrėtojui prieš praleidžiant tikslą, paverčia SLA iš ataskaitos artefakto operacine kontrole.

Pakartotinio atidarymo rodiklis turėtų būti šalia sprendimo laiko. Didelis sprendimų skaičius su dideliu pakartotinio atidarymo rodikliu reiškia, kad bilietai uždaromi, o ne atsakomi.

Automatizavimas, atlaikantis reorganizaciją

Automatizavimą lengva sukurti ir sunku išlaikyti. Daugumoje pagalbos tarnybų susikaupia taisyklės, kurių niekas neprisimena parašęs, ir šis krūvis tampa priežastimi nieko nekeisti.

Trys savybės išlaiko taisyklių rinkinį prižiūrimą. Taisyklės turėtų būti skaitomos kaip sakinys, o ne dekoduojamos iš lentelės. Jos turėtų būti perjungiamos atskirai, kad blogą pakeitimą būtų galima atšaukti neišardant likusios dalies. Ir jas turėtų galėti redaguoti administratorius, o ne programuotojas.

Apimtis svarbi lygiai taip pat, kaip ir sintaksė. Taisyklių variklis, apimantis bilietus, pokalbius, CRM ir balsą, gali vienoje taisyklėje pažymėti pokalbį, priskirti savininką, paleisti laikmatį ir atidaryti sandorį; modulinis variklis kiekvienam žingsniui reikalauja atskiros integracijos.

Talpos ribos ir darbo valandos turėtų priklausyti tam pačiam varikliui, nes maršrutizavimas, kuris ignoruoja tai, kas iš tikrųjų yra laisvas, yra maršrutizavimas, sukuriantis eiles.

DI pagalbos tarnyboje

DI pagalbos tarnybos programinė įranga apima tris skirtingas užduotis, o tiekėjai visas tris apibūdina tuo pačiu žodžiu.

Rūšiavimas yra mažiausiai matomas ir dažnai vertingiausias: klasifikavimas, žymėjimas, prioriteto nustatymas ir nukreipimas be agento skaitymo iš anksto.

Juodraščių rašymas yra tai, ką pastebi agentai. Modelis parašo atsakymą iš patvirtinto turinio, o agentas redaguoja prieš siųsdamas, taip sutrumpinamas apdorojimo laikas nerizikuojant neteisingu atsakymu.

Autonominis atsakymas yra trečias, ir jam reikia daugiausiai turinio už nugaros. Asistentas, pagrįstas šešiais straipsniais, atsako kaip įrankis, perskaitęs šešis straipsnius.

Komercinis klausimas stovi atskirai nuo visų trijų. Apmokestinimas už kiekvieną išspręstą bilietą susieja sąskaitą su tuo, kaip gerai veikia automatizavimas; savo modelio rakto prijungimas išlaiko išvadų kainą didmenine ir palieka modelio pasirinkimą pirkėjui.

Variantai mažam verslui

Pagalbos tarnybos programinė įranga mažam verslui turi tris nepasakytus reikalavimus: žemą pradinę kainą, diegimą, kuris nėra projektas, ir erdvę augti nesikeliant į kitą sistemą.

Pirmieji du dažniausiai patenkinami. Trečiasis - kur iš tiesų priimamas sprendimas, nes migracija po metų kainuoja daugiau, nei kada nors sutaupė licencijos skirtumas.

Praktinis testas yra tai, ar platforma jau turi tai, ko reikės po dvylikos mėnesių. Skambučiai, paskyros įrašas, SLA tikslai pagal lygį ir antra kalba yra keturi dalykai, kurie dažniausiai atsiranda anksčiau, nei tikimasi.

Paprasta pagalbos tarnybos programinė įranga yra tikra kategorija ir pagrįstas pasirinkimas, jei tik paprasta reiškia mažiau nustatymų, o ne mažiau galimybių.

Nemokami planai ir kiek jie kainuoja vėliau

Nemokama pagalbos tarnybos programinė įranga egzistuoja ir veikia, su tiekėjams nuosekliai vienodais apribojimais.

Pirmiausia ribojamos agentų vietos, po to istorijos saugojimas, tada integracijos. Ribos nustatomos tokios, kad auganti komanda jas pasiekia maždaug ketvirtį po įsipareigojimo.

Paslėpta kaina retai yra atnaujinimo kaina. Tai, kad automatizacija, išsaugoti atsakymai ir ataskaitos, sukurtos nemokamu laikotarpiu, gali neišlikti persikeliant pas kitą tiekėją, kai atnaujinimas atrodo nepatrauklus.

RolChat neturi amžinai nemokamo plano. 30 dienų bandomasis laikotarpis atrakina visas funkcijas ir reikalauja kortelės, pirmasis nurašymas įvyksta 31 dieną, o priminimas siunčiamas prieš tris dienas.

Savitarna ir bilietų nukreipimas

Nukreipimas yra vienintelis šios kategorijos svertas, kuris pašalina darbą, o ne jį perkelia.

Pagalbos centras jūsų pačių domene išlaiko srautą ir paieškos vertę; svetainėje esantis tiekėjo subdomene kuria svetimą vertę. Šį pasirinkimą sunku atšaukti, kai straipsniai jau indeksuoti.

Straipsnių analitika ir tuščios paieškos ataskaitos paverčia turinio atsilikimą į eilės pagrįstą sąrašą. Klausimai, kurie kartojasi be jokio straipsnio už jų, yra kiti dalykai, kuriuos reikia parašyti.

Pagrindimas tuo pačiu patvirtintu turiniu palaiko pokalbio atsakymo ir straipsnio nuoseklumą. Du atsakymai į vieną klausimą yra blogiau nei vienas lėtas atsakymas.

Ataskaitos, keičiančios personalo komplektavimą

Dauguma pagalbos tarnybos ataskaitų skaitomos kartą per ketvirtį ir nieko nekeičia. Ataskaitos, kurios keičia sprendimus, yra siauresnės, nei rodo prietaisų skydeliai.

Kiekis pagal paros valandą nulemia pamainų grafikus. Kiekis pagal priežastį nulemia, ką automatizuoti ir ką dokumentuoti. Pakartotinio atidarymo rodiklis nulemia, ar kokybė išlaikoma.

Darbo krūvis pagal agentą yra mažiau svarbus nei darbo krūvio skirtumas tarp agentų: lygi eilė su ilgu vidurkiu yra personalo problema, netolygi - maršrutizavimo problema, ir sprendimas skiriasi.

Ten, kur balsas integruotas natūraliai, skambučių metrika turėtų būti toje pačioje ataskaitoje kaip ir rašytinė. Jų atskyrimas dviejose konsolėse yra būdas, kaip komandos baigia optimizuoti vieną kanalą kito sąskaita.

El. pašto pristatomumas ir adresas, iš kurio atsakoma

El. paštas vis dar yra didžiausias kanalas daugumoje pagalbos tarnybų, o mažiausiai nagrinėjama diegimo dalis - iš kur ateina atsakymai.

Siuntimas iš savo domeno reikalauja DNS įrašų, kuriuos nurodys platforma, o jų praleidimas yra priežastis, kodėl atsakymai patenka į šlamštą po trijų savaičių nuo paleidimo, o ne pirmą dieną.

Gijos - antra detalė. Platforma, laužanti atsakymo grandinę, sukuria dublikuotus bilietus vienam pokalbiui, o tai išpučia kiekio ataskaitas ir erzina klientą.

Persiuntimo taisyklės iš senos pašto dėžutės turėtų būti laikinos. Jų palikimas neribotam laikui reiškia, kad dvi sistemos mano priklausančios tai pačiai užklausai.

Migracija ir priklausomybė nuo tiekėjo

Į kiekvieną čia esančią platformą lengva patekti. Jos skiriasi tuo, kaip lengva iš jų išeiti, ir šis skirtumas nusipelno kainodaros pirkimo metu.

Patikrinkite, ar bilietų istorija eksportuojama naudojamu formatu, ar pagalbos centro straipsniai išlaiko savo URL adresus per peradresavimus, ir ar kontaktai išeina su nepakitusiais pasirinktiniais laukais.

Automatizavimas neperkeliamas tarp platformų, nes modeliai skiriasi. Tekstas makrokomandose ir išsaugotuose atsakymuose perkeliamas, ir jo atkūrimas paprastai yra greitesnis nei originalus kūrimas.

Dvi savaitės lygiagretaus veikimo kainuoja vieną papildomą licencijos laikotarpį ir pašalina didžiąją dalį rizikos. Tai išlieka pigiausiu draudimu šioje kategorijoje.

Vaidmenys, teisės ir audito seka

Pagalbos tarnyba saugo daugiau asmens duomenų nei dauguma įmonės sistemų, o šioje srityje esančios kontrolės priemonės šiame sąraše labai skiriasi.

Vaidmenys turėtų nulemti, kokias eiles žmogus atidaro, kokius laukus jis gali redaguoti, kokias ataskaitas skaito ir kokius eksportus gali paleisti. Skaitymo prieiga prie viso ko yra numatytoji nuostata daugiau produktų, nei turėtų būti.

Audito žurnalas fiksuoja, kas buvo padaryta ir kas tai padarė. Tai dalis, kurios reikalauja auditorius, ir dalis, kurios niekas netikrina, kol neprašoma.

Kelių prekės ženklų ir baltosios etiketės nustatymai svarbūs agentūroms ir grupėms: atskiri prekės ženklai vienoje paskyroje, kur vadovas vis tiek mato juos visus.

Sutikimo tvarkymas turėtų būti šalia pagalbos tarnybos, o ne atskirame tiekėjyje. RolChat siūlo slapukų juostą, slapukų skenerį, sutikimų žurnalą ir DSAR tvarkymą kaip 5 USD papildomą funkciją už svetainę.

Daugiakalbės pagalbos tarnybos

Antra rinka yra dažniausia priežastis, dėl kurios pagalbos tarnybos pasirinkimas peržiūrimas per dvejus metus.

Sąsajos aprėptis yra pirmasis reikalavimas, ir tai nėra tas pats kas turinio aprėptis. RolChat siūlo 40 sąsajos kalbų, o maršrutizavimas gali nukreipti užklausą tam, kas kalba ta kalba, o ne tam, kas laisvas.

Vertimas pokalbio metu pakeičia personalo klausimą iš samdymo pagal kalbą į maršrutizavimą pagal kalbą, o tai skiria rinkos atidarymą nuo jos atidėjimo.

Pagalbos centro straipsniai turėtų turėti kalbų variantus po viena URL struktūra, o ne kaip atskiras svetaines, kitaip antra rinka tampa migracija, o ne vertimu.

Integracijos ir platesnis įrankių rinkinys

Pagalbos tarnyba veikia šalia CRM, atsiskaitymo sistemos, parduotuvės platformos ir kalendoriaus, o tai, kaip ji su jais susijungia, nulemia, kiek kopijavimo agentai atlieka rankiniu būdu.

Du klausimai skiria tikrą integraciją nuo sąrašo įrašo. Ar ji rašo atgal, kad agento veiksmas atnaujintų kitą sistemą, o ne tik skaitytų iš jos. Ir ar ji išlieka veikianti po schemos pasikeitimo bet kurioje pusėje be programuotojo.

Jungiklių skaičiavimas yra prastas galimybių rodiklis. Platformai su natūraliu CRM, bilietais ir balsu jų reikia mažiau nei tai, kuri turi skolintis visus tris, o kiekviena skolinta sistema yra vieta, kur kliento įrašas gali nusidėvėti.

Ten, kur jungiklio nėra, API ir webhookai, perduodantys bilietus, kontaktus ir įvykius abiem kryptimis, yra atsarginis variantas, kurį verta patikrinti bandomojo laikotarpio metu.

Dažnai užduodami klausimai

Ruslan Nazarov

RolChat SEO vadovas

Rašo apie klientų aptarnavimo procesus, pokalbius gyvai, AI padedamą aptarnavimą ir įrankius, kuriais kuriama gera klientų patirtis.

LinkedIn