Palīdzības dienesta programmatūra: izveidojiet efektīvu pieteikumu darbplūsmu

Palīdzības dienesta programmatūra ir visnoderīgākā, kad tā atbalsta skaidru darba kārtību. Rīka iegāde pati par sevi nenosaka, kam pieder pieprasījums, kad biļetei jāgaida vai kas tiek uzskatīts par atrisinātu. Vispirms šie lēmumi ir jāpieņem jūsu komandai.

Šajā ceļvedī parādīts, kā izveidot praktisku biļešu darbplūsmu ap jūsu esošo atbalsta e-pastu. Tajā galvenā uzmanība pievērsta darbības modelim, nevis funkciju salīdzinājumam. Ja vēlaties redzēt, kā e-pasts, piešķiršana, statuss, prioritāte, tagi, piezīmes un biļetes vēsture darbojas kopā vienā produktā, izskatiet Deskhero koplietojamās iesūtnes un biļešu pārvaldības funkcijas, veicot tālāk norādītās darbības.

Sāciet ar ceļu, pa kuru jāvirzās klienta pieprasījumam

Pirms kaut ko konfigurējat, izveidojiet parastā ceļa karti no pieprasījuma saņemšanas līdz atrisināšanai. Noderīga pirmā versija ir vienkārša: ziņojums pienāk, kāds to pārskata, īstais cilvēks uzņemas atbildību, komanda paveic darbu, un klients saņem galīgo atbildi.

Pēc tam uzskaitiet izņēmumus, kas regulāri izjauc šo ceļu. Jautājumam par norēķiniem var būt nepieciešama cita komanda. Tehniskai problēmai var būt vajadzīga izpēte. Klients var pārstāt atbildēt. Divi ziņojumi var aprakstīt vienu un to pašu problēmu. Šie gadījumi parāda, kādi statusi, nodošanas procesi un drošības pasākumi ir nepieciešami jūsu darbplūsmai.

Koncentrējiet karti uz lēmumiem. Katram posmam atbildiet uz šiem jautājumiem:

• Kurš ir atbildīgs par nākamo darbību?
• Kādai informācijai jābūt pieejamai, pirms biļete var virzīties uz priekšu?
• Kam jānotiek, ja atbildīgais cilvēks nav pieejams?
• Kā cits User var saprast pašreizējo stāvokli, neprasot kopsavilkumu?
• Kāds notikums nozīmē, ka pieprasījums patiešām ir pabeigts?

Darbplūsma ir efektīva, ja jebkurš User var atvērt biļeti un saprast, kas noticis, kas notiks tālāk un kurš ir atbildīgs par nākamo soli.

Izmantojiet nelielu statusu kopumu ar precīzām nozīmēm

Statusu nosaukumi bieži šķiet pašsaprotami, taču komandas tos interpretē atšķirīgi. Definējiet katru statusu pēc tā, kam jāveic nākamā darbība. Šis vienīgais noteikums novērš daudzu biļešu iestrēgšanu.

Neveidojiet statusu katrai nodaļai, tēmai vai steidzamības līmenim. Izmantojiet piešķiršanu vai grupas atbildības noteikšanai, tagus tēmām un prioritāti steidzamībai. Ja katram laukam ir viens mērķis, Users var konsekventi pārskatīt rindu.

Atdaliet atbildību, prioritāti un klasifikāciju

Šie trīs jēdzieni atbild uz dažādiem jautājumiem. Atbildība norāda, kam jārīkojas. Prioritāte parāda, cik ātri jāpievērš uzmanība. Klasifikācija norāda, kāda veida pieprasījums tas ir. To jaukšana rada neskaidras rindas un neuzticamus pārskatus.

Nosakiet vienu User vai grupu par atbildīgo

Katrai atvērtai biļetei jābūt skaidram atbildīgajam. Dalīta atbildība viegli pārvēršas par nekādu atbildību. Grupa var saņemt jaunu darbu, taču, tiklīdz darbs sākas, to vajadzētu pārņemt konkrētam User. Definējiet aizvietošanas noteikumu prombūtnes gadījumiem un nodošanas noteikumu, ja mainās nepieciešamā kompetence.

Definējiet prioritāti ar novērojamiem nosacījumiem

Uzrakstiet prioritātes noteikumus vienkāršā valodā. Piemēram, pārtraukums, kas ietekmē daudzus klientus, ir svarīgāks par vispārīgu jautājumu. Neļaujiet prioritātei kļūt par veidu, kā katru nepacietīgu pieprasījumu atzīmēt kā steidzamu. Īsa rakstiska definīcija sniedz Users pamatojumu, ko viņi var konsekventi piemērot.

Izmantojiet tagus turpmākai rīcībai, nevis dekorēšanai

Izveidojiet tagu tikai tad, ja tas palīdz komandai novirzīt darbu, atrast noderīgu segmentu vai atbildēt uz atkārtotu jautājumu. Periodiski pārskatiet tagus un apvienojiet gandrīz identiskus tagus. Mazāks jēdzienu kopums nodrošina tīrākus skatus un uzticamāku analīzi.

Izveidojiet nodošanas procesu, kas saglabā kontekstu

Nodošanai vajadzētu pārnest atbildību, neliekot nākamajam User no jauna rekonstruēt gadījumu. Saglabājiet klientu atbildes un privātās piezīmes biļetes laika skalā. Pirms atkārtotas piešķiršanas pievienojiet pašreizējo secinājumu, neatbildēto jautājumu un nākamo paredzēto darbību.

Izmantojiet iekšējās piezīmes sadarbībai, kas nav jānosūta klientam. Izmantojiet atbildi klientam, kad nepieciešams apstiprināt saņemšanu, pieprasīt informāciju vai izskaidrot kavēšanos. Šī atšķirība uztur sarunu skaidru un sniedz kolēģiem nepieciešamo kontekstu.

Ja divas biļetes attiecas uz vienu un to pašu problēmu, izlemiet, kurš ieraksts būs galvenais informācijas avots. Apvienojiet dublikātu ar galveno biļeti un turpiniet darbu vienuviet. Paralēli ieraksti rada pretrunīgu atbilžu risku un sadala vēsturi.

Pievienojiet pakalpojumu mērķus pēc darbplūsmas stabilizēšanas

Mērķi nevar novērst neskaidru atbildību. Vispirms pārliecinieties, ka jaunie darbi tiek pārskatīti, piešķīrumi ir redzami un gaidošajām biļetēm ir paredzēts turpmākās rīcības ceļš. Pēc tam nosakiet atbildēšanas un atrisināšanas gaidas atbilstoši stundām, kurās jūsu komanda faktiski strādā.

Pievērsiet uzmanību biļetēm, kurām tuvojas mērķa termiņš, ne tikai tām, kurām tas jau ir nokavēts. Mērķis ir rosināt rīcību, kamēr vēl ir laiks. Deskhero SLA politikas atbalsta pirmās atbildes un atrisināšanas mērķus, darba laika grafikus, filtrus, brīdinājumus un informācijas paneļa skatu.

Pārbaudiet darbplūsmu ar reāliem scenārijiem

Pirms ieviešat procesu, izspēlējiet tipiskus pieprasījumus. Iekļaujiet vienkāršu jautājumu, pieprasījumu, kurā mainās atbildīgais, gadījumu, kurā jāgaida klienta atbilde, dublikātu un atkārtoti atvērtu sarunu. Katrā scenārijā pārbaudiet, vai nākamā darbība un atbildīgais joprojām ir skaidri saprotami.

Veiciet pārbaudi ar Users, kuri nav izstrādājuši darbplūsmu. Ja viņiem nepieciešami mutiski norādījumi, noteikumi vai lauku nosaukumi vēl nav pietiekami skaidri. Pielāgojiet procesu un pēc tam atkārtojiet scenārijus.

Ieviešanas laikā uzturiet īsu izņēmumu žurnālu. Pierakstiet situācijas, kurās Users nezina, kādu statusu, atbildīgo vai prioritāti izvēlēties. Regulāri pārskatiet šo žurnālu un mainiet darbplūsmu tikai tad, kad parādās atkārtots modelis. Tas neļauj sistēmā uzkrāties vienreizējiem noteikumiem.

Novērtējiet plūsmu, nevis aktivitāti pašas aktivitātes dēļ

Noderīgi pārskati atklāj, kur klientiem jāgaida un kur darbs iestrēgst. Sāciet ar biļešu apjomu, laiku līdz pirmajai atbildei, atrisināšanas laiku, neizskatīto biļešu vecumu un atkārtoti atvērtajiem pieprasījumiem. Skatiet tendences un segmentus, nevis uzskatiet vienu vidējo rādītāju par visu situāciju.

Katram rādītājam piesaistiet lēmumu. Pieaugošs vecu biļešu uzkrājums var liecināt par nepieciešamību skaidrāk noteikt atbildību vai palielināt kapacitāti. Lēnas pirmās atbildes var norādīt uz nepietiekamu jauno pieprasījumu uzraudzību. Bieža biļešu atkārtota atvēršana var liecināt par nepilnīgiem risinājumiem vai neskaidrām atbildēm. Lai izveidotu padziļinātu mērījumu plānu, skatiet mūsu ceļvedi par palīdzības dienesta pārskatu rādītājiem.

Pārskatiet darbplūsmu, kad pierādījumi parāda atkārtotu šauro vietu. Nepievienojiet laukus vai darbības tikai tāpēc, ka programmatūra to ļauj. Labākā palīdzības dienesta konfigurācija ir mazākā iespējamā konfigurācija, kas uzticami padara redzamu atbildību, kontekstu un nākamās darbības.

Praktisks ieviešanas kontrolsaraksts

1. Izveidojiet parastā pieprasījuma ceļa un biežāko izņēmumu karti.
2. Definējiet katru statusu pēc tā, kam jāveic nākamā darbība.
3. Atdaliet atbildību, steidzamību un tēmas klasifikāciju.
4. Dokumentējiet, kam jābūt iekļautam pilnīgā nodošanā.
5. Pārbaudiet darbplūsmu ar reālistiskiem atbalsta scenārijiem.
6. Pievienojiet pakalpojumu mērķus, kad maršrutēšana un atbildība ir uzticama.
7. Izvēlieties nelielu rādītāju kopumu, kas saistīts ar operatīviem lēmumiem.
8. Pārskatiet izņēmumus un vienkāršojiet noteikumus, kurus Users piemēro nekonsekventi.

Kad šie lēmumi ir pierakstīti, konfigurēšana kļūst daudz vienkāršāka. Jūsu rīkam jāpadara saskaņotais process redzams un atkārtojams, vienlaikus saglabājot pietiekamu elastību neparastiem gadījumiem.