WHO IT'S FOR

One agent.
More capacity at every seat.

Everyone on the instance is asking it questions it can already answer — the difference is only how long it takes them to get there. Kaddiya is the same agent for all three seats below; what changes between them is the roles the person signed in with, and therefore what the agent can see. What doesn't change is the last step: somebody reads the draft and approves it.

Illustration: a service-desk agent at her laptop, looking up from the screen, with composed cards around her — a draft reply marked Ready for review, a checklist reading Analyze record, Find related tasks and Draft response all ticked with Awaiting approval still open, and an Update record card listing proposed changes above a Review button.
SERVICE DESK

The queue becomes a review pass

Forty open tickets, and the answer to a third of them is already somewhere in the instance — in a resolved case from March, in a knowledge article nobody links, in the journal of the ticket sitting two rows down.

Ask what's on your plate. Kaddiya pulls each case, reads the whole journal rather than the short description, looks for the last time someone fixed the same thing, and hands back a draft reply. Claude does the reading. You keep the judgment, and you press Send.

WHAT IT DOES NOT DO

It does not resolve or close your tickets, reassign them, or reply to anyone on its own. The draft sits there until you send it, and if you never do, nothing was written.

my queue · prior fixes · drafts behind a button
INC0048291VPN drops during renegotiation
INC0048307Cannot reach EMEA file share
INC0048312Tunnel resets every 8 hours
INC0048318Laptop will not join the domain
INC0048320MFA prompt loop on Android
DRAFT REPLY pending your approval
Hi Priya — we've identified the cause: the EMEA concentrator was dropping tunnels during key renegotiation. A firmware fix is applied and under monitoring now.
Nothing is written until you press Send.Send
Five cases in, one draft out — and the draft is still a draft.
DEVELOPERS

A senior colleague who read all the docs

You know the platform. What you don't know is this instance's particular forty customizations — which field was renamed, which business rule fires first, what the last person's update set actually captured.

Schema truth instead of guessing. Encoded queries you can lift straight into your own work. The update set checked before anything is proposed. Complete scripts written for your review, grounded in the documentation for the release your instance is actually running — with the topic it used cited underneath.

WHAT IT DOES NOT DO

It does not commit code. A script arrives as a proposal card showing the exact payload; creating the record and creating an update set are each their own click, on your credentials.

sn_schema · update sets · full scripts · docs cited
WHAT IT CHECKED FIRST
SCHEMA · incident 0.21 s · 74 fields
u_network_segment → cmdb_ci_network
UPDATE SET · current 0.09 s
NC — August fixes · in progress
It reads the instance before it writes you a line of script, because the script is worthless if the field name is a guess.
Real tool cards. The same ones you'd see in the console, in run order.
LEADS & ADMINS

Answers about the instance, not anecdotes

Breaches by group. Ageing P2s. Who holds which role, and who quietly still holds it after changing teams. Why an ACL denied that row when the user swears they have the role.

Questions that used to be a report request, or a favour asked of the one person who writes good encoded queries, become a sentence. Every query it ran is on screen while it runs, so the number in the answer is one you can check — or re-run yourself tomorrow without asking anyone.

WHAT IT DOES NOT DO

It is not a BI tool and keeps no dashboard. Each answer is computed from queries against your instance at the moment you ask, which is also why the queries are shown rather than summarised.

every query shown · every commit named
ONE QUESTION, TWO QUERIES, AN ANSWER
"Which groups breached SLA more than twice this month?"
AGGREGATE · task_sla 0.44 s · 9 groups
has_breached=true^sys_created_onONThis month^GROUPBYtask.assignment_group
QUERY · sys_user_grmember running · 0.3 s
group.nameINNetwork Ops,Service Desk L2^user.active=true
Three groups, and two of them are the same four people. The queries are ServiceNow's own encoded syntax — if you can read your instance, you can read what the agent asked it.
The answer is only as good as the query, so the query is not hidden.
THE SEAT YOU DON'T HAVE TO BUY
Three seats, one agent, and no per-person configuration.

There is no service-desk edition and no developer edition. It is one agent, and the reason it behaves differently for the three people above is that they signed in as themselves: their roles, their groups, their user criteria. A service-desk agent sees the queues they're on. A developer with personalize_dictionary sees the dictionary. Neither of them sees anything the other's roles wouldn't have shown them anyway.

That is also why there is nothing to provision. You don't map people to seats, license them by persona, or maintain a second directory — the instance already knows who everyone is, and we ask it rather than duplicating it.

The permission model is not a feature we built. It is your instance, doing what it already does.

DW Dana Whitfieldservice desk · acme.service-now.com
SEES, BECAUSE OF THESE ROLES
itilsn_incident_readknowledge
DOES NOT SEE
sys_dictionarysys_user_has_rolehr_case
Not a setting of ours. A 403 from your instance.