Human-centered design systems and product experiences
Core services
01UI/UX Design02Web Development03Software Development042D/3D Experiences05App Development06AI Agents & Automation07Website DesignTechnical services
Frontend Engineering
React DevelopmentNext.js DevelopmentWeb ApplicationsEnterprise DashboardsSaaS PlatformsBackend & Infrastructure
API DevelopmentCloud InfrastructureDevOps & CI/CDBackend SystemsCustom SoftwareIndustries we serve
Technology & Software
AI IT Helpdesk Agent Development
Fixed by the runbook, or escalated
An agent for the first line of IT support.
An agent for the first line of IT support. It matches an employee's issue to your runbook, asks the diagnostic questions, gives the steps, can run a small fix you listed on the person's own device, and escalates the rest with what it learned.
Most tickets are the same thirty problems. The printer queue, the VPN profile, the mailbox that stopped updating. A technician answers them from memory while the unusual ticket waits. Automating this is tempting and risky, because the same channel also receives "reset my password" and "give me admin rights", and an eager assistant will try to help with those too.
What exists today is a working demonstration on test data, which we can walk you through. It shows a routine issue resolved from its runbook with one permitted fix, an unfamiliar issue escalated without advice, and password, access and deletion requests opened for approval with nothing carried out. Connecting it to your own systems is the project.
One Case, Start to Finish
An example of one case, in 6 steps. The same steps play in the picture at the top of this page.
Issue reported
"I can't print, everything is stuck in the queue" arrives with the employee's identity from your sign-in.
Runbook found
The report matches your runbook for stuck print queues. The first diagnostic question is asked.
Scope checked
"Only me" continues the runbook. "The whole floor" would have escalated it as an outage.
Steps given
The runbook's steps are given, with an offer to restart the printing service on the person's laptop.
Fix run
The person agrees. The fix runs once, on the device registered to them, and the result is reported.
Confirmed or escalated
"Yes, it prints" closes the ticket with the trace. "No" sends it to a technician with everything so far.
How the Work Is Done Today
The same ticket every day
Technicians retype the same steps while new problems queue behind them.
Advice from nowhere
A helpful answer that is not in any runbook and breaks something else.
Sensitive requests in the same queue
Password resets and access requests arrive next to printer problems.
Acting for someone else
"Please reset it for my manager" sounds reasonable and is how accounts get taken over.
A fix that ran is not a fix
The script completed and the problem is still there, but the ticket says resolved.
The same problem every morning
A workaround is applied daily and the real fault is never looked at.
Six jobs it carries through
Runbook matching
Finds the approved runbook for the issue.
- Matches the report to your runbooks
- Warns when a runbook is past review
- Says when none applies
- Suggests nothing of its own
Diagnostic questions
Asks what the runbook needs to know.
- One question at a time
- Records each answer
- Escalates when an answer points elsewhere
- Stops before guidance if others are affected
Guided steps
Gives the runbook's steps in order.
- The approved steps, word for word
- Then asks whether it worked
- A no goes to a technician
- The trace goes with it
Permitted fixes
Runs one low-impact fix from your list.
- Only after the person agrees
- Only on a device registered to them
- Once per case, with a daily limit
- Says plainly when it did not complete
Approval routing
Sends sensitive requests where they belong.
- Password and sign-in resets
- Access and admin rights
- Wiping and deleting
- Suspected security incidents
Escalation with a trace
Hands a ticket to a technician with what was learned.
- The report in the person's words
- The answers given
- The fix tried and its result
- The reason it was escalated
Walk One Real Case Through It
Thirty minutes, one case from your own process. We map it against the workflow on this page and tell you plainly what can be reused from our demonstrations and what has to be built for your systems.
A Short List of What It May Do, and Nothing Else
You keep two lists. One names the small fixes the agent may run without approval, each with a daily limit per person. The other names the kinds of request it must never carry out: resets, access, deletions and security incidents. Those are opened in your approval queue with the person's words, and nothing is changed.
The agent acts only for the person who is asking, on a device your records assign to them. A request about someone else's account is passed to your team, not acted on.
- Guidance only from your runbooks
- A fixed list of permitted fixes
- Resets and access go to approval
- Only the requester's own device
- No fix reported until confirmed
- Every ticket carries its trace
What It Reads and Writes
The systems named here are the kind this agent works with. Which ones it connects to in your case is settled in the scope.
Tickets
- ServiceNow
- Jira Service Management
- Freshservice
- Zendesk
Devices
- Microsoft Intune
- Jamf
- or your device management tool
Identity
- Microsoft Entra ID
- Okta
- Google Workspace
Runbooks
- Your knowledge base
- Confluence
- SharePoint
Where staff ask
- Slack
- Microsoft Teams
- your service portal
Approvals
- The queues your identity, access and change processes already use
What Buyers Ask First
Can it reset passwords or grant access?
No. Requests about credentials, access, admin rights, deleting or wiping are opened in your approval queue and nothing is carried out. The agent has no connection that could perform them. Whether to automate any of these later is a decision for your security team, through your own approval path.
How is this different from the internal knowledge agent?
The knowledge agent answers questions from documents and stops. This agent works a ticket: it asks diagnostic questions, runs a permitted fix on the person's own device, checks whether it worked and escalates with a trace. Both can read the same runbooks.
What happens when it meets a problem it has no runbook for?
It says so, suggests nothing, and opens a ticket for a technician with the report in the person's own words. Writing the missing runbook is a job for your team. The list of issues that had no runbook is a useful by-product.
What exists today?
A working demonstration on test data. It shows a routine issue resolved from its runbook with one permitted fix, an unfamiliar issue escalated without advice, and password, access and deletion requests opened for approval with nothing carried out. It is not connected to live systems, so the project is the integration with your own systems, your rules and a controlled pilot.
Start With Your Ten Most Common Tickets
Bring the runbooks you have, or the tickets if you have none. We will show which can be handled end to end, which need a runbook first and which should never be automated.