Chatboty pre interný IT support: prečo demo neznamená nasadenie

Chatboty pre interný IT support: prečo demo neznamená nasadenie

Demo chatbota trvá tri minúty: „Reset hesla", „OK, posielam link", hotovo. Vyzerá to skvele. Polrok po nasadení do reálnej prevádzky vyzerá situácia inak: helpdesk dostáva eskalácie z botových odpovedí, používatelia sa naučili, že bot vie iba „možno reset hesla", a IT manažér odpovedá na otázku „aký je ROI". Tento článok je deployment playbook — krok po kroku, čo treba urobiť, aby chatbot v IT support skutočne fungoval, nie iba odovzdal demo.

Krok 1: KB audit pred botom

Chatbot odpovedá iba tak dobre, ako je jeho zdroj. Pre vnútorný IT support to obvykle znamená Knowledge Base v GLPI, Confluence alebo iný KB tool. Pred zapnutím bota:

  1. Vyextrahujte top 50 najčastejších tiketov za posledné 3 mesiace. Identifikujte témy, ktoré tvoria 60 – 80 % objemu (typicky: reset hesla, prístup do systému, VPN problémy, tlačiarne, M365 issue).
  2. Pre každú tému overte, či existuje aktuálny KB článok. Ak nie, napíšte ho. Ak áno, overte aktuálnosť — verzie systémov, screenshoty, kroky.
  3. KB články prepíšte do bot-friendly formátu — krátke odseky, kroky 1, 2, 3, jasný „ak nefunguje, kontaktuj X".
  4. Definujte explicit „neviem" témy — kde bot nemá odpovedať, ale rovno eskalovať. Príklady: technické chyby v špecifickom internom softvéri, security incidenty, GDPR otázky.

KB audit zaberie 2 – 4 týždne. Bez neho chatbot je len drahá náhrada za neaktuálny FAQ.

Krok 2: intent mapping

Bot musí rozpoznať, čo používateľ chce, aj keď to formuluje rôzne. „Zabudol som heslo", „Nemôžem sa prihlásiť", „Heslo mi vyprší" sú tri vyjadrenia toho istého intent-u password reset. Mapping intent-ov:

Intent: password_reset
  Triggers: "heslo", "prihlásenie", "login", "M365"
  Action: provide KB article #42 + offer self-service link
  Confidence threshold: 0.85
  Fallback: create ticket "Reset hesla" with category L1/Access

Intent: vpn_issue
  Triggers: "VPN", "diaľkový prístup", "remote", "Forticlient"
  Action: ask for OS, then KB#67 (Mac) or KB#68 (Windows)
  Confidence threshold: 0.75
  Fallback: create ticket with L1/Network category

Intent: provision_account (escalate, no auto-action)
  Triggers: "nový kolega", "vytvoriť účet", "onboarding"
  Action: NO automated provisioning — too risky
  Always create ticket + assign HR for validation

Confidence threshold je dôležitý: pri nízkej istote (pod 0.7) bot radšej pýta upresnenie alebo eskaluje, než aby uhádol nesprávnu KB.

Krok 3: integrácia s GLPI

Pri eskalácii alebo automatickom vytvorení tiketu bot volá GLPI REST API. Endpoint /apirest.php/Ticket s POST body:

{
  "input": {
    "name": "[Bot] Reset hesla pre Karol Novák",
    "content": "Bot conversation summary:\\n\\nUser: Zabudol som heslo\\nBot: Posielal som KB#42, neúspech\\nUser: Stále nefunguje",
    "users_id_requester": 142,
    "itilcategories_id": 8,
    "type": 2,
    "_source": "chatbot"
  }
}

Polia _source: chatbot a custom field „Bot intent" umožnia neskorší reporting — koľko tiketov bot deflectoval, koľko eskaloval, na ktorých intent-och bol najúspešnejší.

Krok 4: escalačné triggers

Bot musí byť agresívny v eskalovaní. Triggers:

  • Confidence pod prahom — okamžite eskaluj na človeka.
  • Tretia neúspešná interakcia v session — používateľ odpovedá „nepomohlo, nepomohlo, nepomohlo". Bot prestane skúšať.
  • Frustrácia z textu — kľúčové slová „nefunguje", „pomôžte", „prosím", emóciie. Eskaluj.
  • Bezpečnostné/finančné kľúčové slová — „phishing", „incident", „faktúra", „compliance". Vždy eskaluj, nikdy neodpovedaj sám.
  • Mimo working hours — bot môže odpovedať z KB, ale na netriviálne otázky vytvorí tiket pre on-call shift.

Časté pitfalls

  • Halucinácie v LLM-based botoch — bot si vymyslí KB článok #99, ktorý neexistuje. Riešenie: retrieval-augmented generation s pevnou citáciou KB ID, nie voľná generácia.
  • Zastaraná KB — IT zmení proces, ale KB ostáva pôvodná. Bot odpovedá podľa starej. Riešenie: KB články musia mať vlastníka a quarterly review.
  • Žiadny feedback loop — bot odpovedá „pomohla vám táto odpoveď?", ale nikto sa na výsledok nepozerá. Riešenie: weekly report, kde sa pozrú na top 10 negative feedback a opravia KB.
  • Duplikácia tiketov — používateľ skúsil bota, neúspech, vytvoril tiket cez portál. Bot eskalácia + manuálny tiket = dva tikety o tom istom. Riešenie: deduplikácia podľa requester + similarity skóre v posledných 24h.
  • Predaj vyšší než nasadenie — vendor sľúbi „90 % deflection rate". Reálne číslo pre dobre zaintegrovaný bot je 25 – 40 % a je to úspech.

Pilot before rollout

Pilotovať na 50 – 100 používateľoch zo dvoch oddelení 4 – 6 týždňov. Sledovať: deflection rate, escalation rate, CSAT z chatbot interakcií, skutočne uzatvorené tikety bez ľudskej ruky. Po pilote vyhodnotenie — ak deflection < 15 %, vrátiť sa k Krok 1 (KB audit) a vylepšiť. Až keď je > 25 %, robí sa firmw-wide rollout.

Chatbot nie je „náhrada L1 helpdesku". Je to filter pred L1, ktorý zachytí jednoduché, opakované, dobre dokumentované požiadavky. Pre tie, kde by bot mal len 60 % šancu na správnu odpoveď, je rýchlejšie a lacnejšie pre používateľa, aby ticket otvoril rovno na technika.

Potrebujete pomôcť s touto témou?

Kontakt