First-line answers desk
A large part of the service desk queue is questions the documentation already answers, asked by someone who could not find it. This agent answers in the channel people already use, quoting the runbook and linking to it. When it cannot answer, it gathers the detail and raises a ticket instead.
Step by step
Index the IT documentation
Runbooks, how-to pages and known issues are indexed from the wikis and stores IT connects, keeping their access rules.
Take the question in the channel
Someone asks in plain language, in Slack, without opening a form or picking a category first.
Answer from the runbook
The reply gives the steps and links the page and version they came from, so the asker follows the current process.
Ask the clarifying question
Where the answer depends on the device, the site or the role, the agent asks instead of guessing which runbook applies.
Gather the ticket detail
If the documentation does not answer it, the agent collects the details the service desk always asks for, so the ticket arrives complete.
The requester confirms the ticket
The requester sees the drafted ticket and confirms before it is raised. Nothing lands in the queue without them.
Exactly what this agent can see, touch and change
The same five controls sit behind every Askollo agent. These are this one's settings — visible before you build it, not buried in an admin screen afterwards.
Context
What reaches the modelIT service desks whose queue fills with password, access and how-do-I questions, and teams whose documentation is good but rarely opened.
Escalation
When it asks a personThe requester confirms the details before a ticket is raised
Applications & Rights
Which tools it uses, and what it may do in each
ConfluenceRead only
NotionRead only
SharePointRead only
SlackReadWrites newCreates new records or documents. Never edits, moves or deletes anything that was already there.
JiraWrites newCreates new records or documents. Never edits, moves or deletes anything that was already there.Verification
How you know it’s rightEvery claim links to the document it came from. A statement the agent cannot cite does not make it into the output — which is what makes the result reviewable in minutes rather than re-read end to end.
Who it’s for
IT service desks whose queue fills with password, access and how-do-I questions, and teams whose documentation is good but rarely opened.
What you’ll need
- Runbooks in a connected wiki
- An agreed list of topics it may answer
- Channel access for the agent
- A ticket queue to write to
What you get
- Cited answers in the channel
- Complete tickets when it cannot answer
- A log of questions the documentation missed
What it doesn’t do
It answers from documentation and raises tickets. It does not reset passwords, grant access, change a device setting, or act on any system on the asker's behalf.
We build the first one with you
Not a template you configure alone. We sit with your team, build it on real data, and hand over the controls.
Scope
One session with the people who actually do the work. We agree what the agent reads, what it may write, and who approves.
Co-build
Built on your own data, not a sandbox. You watch it being made, so you know why it behaves the way it does.
Handover
You own the controls. Change the context, tighten the rights, move the approval gate — without coming back to us.
Parts of the work currently spread across the categories below. It does not replace any of those products outright.
Frequently asked
Does it reset passwords or grant access?
No. It holds no rights in your identity or device tooling. It explains the current process, and where an action is needed it prepares the ticket so a person with the right permissions carries it out.
What if the runbook is wrong?
Then the answer will be wrong in the same way, which is why every answer cites the page it came from. The log of questions it could not answer, plus corrections from the desk, tells you which runbooks need work.
Will it stop people opening tickets?
It is not meant to. It answers what the documentation covers and helps everything else arrive as a complete ticket. Teams tend to find the queue changes shape more than it shrinks, with better detail on what remains.
Can we limit which topics it answers?
Yes. The topics it may answer are configured during the co-build, and anything outside them goes straight to a ticket. Most teams start narrow, with a few well-documented areas, and widen it as the documentation improves.