Väčšina článkov o GLPI self-service portáli popisuje, ako vyzerá. Užitočnejšia otázka znie, čo koncový používateľ dokáže vybaviť bez toho, aby písal na IT — pretože presne podľa toho sa portál hodnotí. Portál, ktorý vyzerá čisto, ale každú interakciu aj tak posunie na technika, nevyriešil nič. Tu je poctivý zoznam toho, čo štandardný GLPI portál podporuje, a čo si vyžaduje trocha konfigurácie, aby sa stal naozaj použiteľným.
Zadanie tiketu tak, ako má byť
Primárnou úlohou portálu je zadávanie tiketov. GLPI zobrazuje zjednodušený formulár — kategória, názov, popis, lokalita, prípadne urgentnosť — obmedzený podľa profilu používateľa. To, čo rozhoduje, sú šablóny tiketov. Šablóna viazaná na kategóriu dopredu vyplní polia a niektoré označí ako povinné: kategória „Tlačiareň nefunguje“ by mala vyžadovať tlačiareň ako aktívum, poschodie a krátky popis. Bez toho je prvou odpoveďou technika vždy „o ktorú tlačiareň ide?“, a to je polovica dôvodu, prečo používatelia prestanú používať self-service a začnú ľuďom písať cez Teams. Opravte šablónu a polovica sťažností na portál zmizne.
Sledovanie a komentovanie existujúcich tiketov
Keď už tiket existuje, používateľ ho vie sledovať: aktuálny stav, prideleného technika, SLA čas, každý komentár, ktorý technik pridá. Môže pridávať vlastné komentáre, dopĺňať screenshoty a schváliť riešenie pred zatvorením tiketu. Zapnutie schválenia riešenia stojí za to — znamená to, že tiket zostáva na strane používateľa, kým reálne nepotvrdí, že problém zmizol, nie keď si to myslí technik. Tikety sa zatvárajú pomalšie, ale zatvárajú sa správne, a počty znovuotvorených tiketov do druhého dňa viditeľne klesnú.
Prehľadávanie databázy znalostí
GLPI má KB funkciu, ktorá je často nedoceňená. Články sa dajú označiť ako viditeľné pre koncových používateľov a portál ich ponúka v prehľadávateľnom katalógu. Ak je článok naviazaný na kategóriu tiketu, vynorí sa aj vtedy, keď používateľ práve zadáva tiket v tej kategórii — upozornenie „skôr než odošlete, skúsili ste toto?“, ktoré uzatvára slučku bez toho, aby to prešlo cez helpdesk. Či to reálne zníži objem tiketov, závisí výhradne od toho, či v KB sú skutočné a overené riešenia. Ak sa články dopisovali v panike deň pred spustením, používatelia ich do druhého týždňa prestanú čítať.
Pohľad na vlastné aktíva
Ak je v GLPI inventári väzba medzi aktívami a používateľmi, portál dokáže každému používateľovi ukázať jeho pridelený počítač, telefón, monitor a softvér. Znie to ako kozmetika, ale má to konkrétny úžitok: keď používateľ zadáva tiket, vie presne vybrať aktívum, ktorého sa problém týka, a technik nemusí hádať, ktorý z troch notebookov v CMDB je ten s pokazeným reproduktorom. Zároveň to ušetrí konverzácie typu „aký je váš inventárny štítok?“, ktoré sa na každom service desku dejú minimálne raz denne.
Schvaľovanie požiadaviek
Pre organizácie, ktoré GLPI používajú aj na požiadavky (softvérové licencie, hardvérové objednávky, prístupové žiadosti), je portál aj miestom, kde manažéri schvaľujú alebo zamietajú požiadavky pridelené im. Jedna obrazovka, jedno kliknutie, záznam v tikete pre audit. Býva to typicky prvé ne-IT použitie portálu, ktoré reálne chytí, pretože nahrádza e-mailové vlákno niečím, čo skutočne eviduje, kto čo schválil a kedy — presne to, na čo sa interný audit neskôr opýta.
Čo nastaviť ako prvé
Portál bežiaci na predvolených nastaveniach nepomáha nikomu. Minimálna konfigurácia, ktorú stojí za to urobiť skôr, než dostanú prístup reálni používatelia: rozhodnúť, ktoré kategórie tiketov sú viditeľné koncovým používateľom (skryť všetko interné — change management, záznamy problémov, polia s citlivými údajmi), vytvoriť šablóny pre top päť kategórií s povinnými poľami, pripraviť päť až desať KB článkov pre najčastejšie tikety a zapnúť „schváliť riešenie“. Zvyšok môže počkať, kým používatelia sami povedia, čo im chýba. Portál nemusí byť kompletný — musí odstrániť prvých pár dôvodov, prečo by ho niekto obchádzal.