Triage that reads your documentation, and a knowledge base that keeps itself current. Your KB gets better every time a technician solves something differently, and nothing is published without their approval.
Two Uses
Connect Hudu once and your documentation works for you at both ends of a ticket's life: when it arrives, and when it's resolved.
When a ticket arrives, DaemonLayer searches the client's Hudu company for assets (by device name, serial, IP address or ticket keywords, including custom fields) and for KB articles and procedures by topic. Triage and the first response use your documented procedures and device details, not generic knowledge. Nothing is written to Hudu.
When the ticket is resolved, DaemonLayer compares what the technician actually did with the articles used during triage. Where an article has drifted, it drafts a minimal edit for a technician to approve or reject.
How It Works
KB Drift Review runs in the background after a ticket is resolved. No configuration beyond switching it on.
The technician's resolution notes are fetched from your PSA. No notes, no draft: the workflow exits cleanly.
Each article used during triage is compared with what was actually done: matches, diverged (worked) where a different approach fixed it, diverged (failed) where the documented approach was tried and failed, or nothing usable.
For diverged articles only. The rest of the article stays word for word, formatting is preserved, and the edit only uses facts from the resolution notes or the existing article. A one or two sentence summary explains what changed and why.
The draft lands on the KB Drafts page with a side-by-side diff of the current and proposed article, the classification and the rationale.
Approve and the update is published to Hudu. Reject and the article is unchanged. If someone edited the live article after the draft was made, the draft is marked Superseded instead of overwriting their work.
KB articles are never updated automatically. Every change is a draft until a technician approves it, and the AI is only allowed to use facts that are already in the resolution notes or the article.
Built To Stay Out Of The Way
One Hudu connection covers every client; each client is matched to its Hudu company on the Clients page. Clients without a match are skipped cleanly, and if Hudu is unreachable, enrichment is skipped silently and the ticket carries on.
The same documentation also grounds the suggested first checks in every RMM handoff, so a technician picking up an escalated alert sees your own procedures first.
Related
Connect your PSA, and DaemonLayer starts triaging, resolving, and routing, no scripting, no setup calls. Cancel anytime.
Prefer a walkthrough? Book a demo →
