Intents

Intents are for the requests you see over and over — a new starter, a hardware request, a mailbox permission change. For each intent you tell Neo what details to collect, in plain language. Neo then runs a consistent intake every time: it gathers exactly the information your team needs before work starts, instead of a technician chasing the requester for the start date or the 2FA number afterwards. Intents work on two kinds of agents, and you choose which with the intent’s Applies to setting:

• End-user chat — your branded end-user bot recognises the request in conversation, asks the intake questions, and files the ticket.
• Triggered agents — a ticket-triggered agent recognises the request on an inbound ticket (typically an email), checks what the ticket already answers, and asks the end user only for what’s missing.

An intent can apply to one surface or both — the same “New Starter” intent can drive your chat bot and your email-intake agent.

​

How it works in chat

When an employee’s request matches one of the intents offered to their company, the bot:

1. Recognises it from the short menu of intents set up for that employee’s company.
2. Pulls up the intake questions for that intent on demand — so the bot’s instructions stay small no matter how many intents you add.
3. Asks only what it doesn’t already know from the conversation, one dependent question at a time, exactly like a good technician taking the request.
4. Files the ticket to the agent’s configured Create Ticket destination, with everything collected in the body.

If nothing matches, the bot simply handles the request as normal free-form conversation. Intents add structure to the common cases; they never get in the way of the rest.

​

How it works on a triggered agent

Most requests don’t arrive in a chat — they arrive as an email that becomes a ticket. Give an intent the Triggered agents surface and assign it to a ticket-triggered agent (for example the agent watching your service-request board), and that agent gains the same structured intake:

1. Recognises that the new ticket matches one of your intents — most tickets won’t, and the agent is explicitly told never to force a match.
2. Loads the intake questions for that intent.
3. Compares them against what the ticket already contains — the original email and any replies.
4. Asks the end user only for what’s missing, in one client-facing note, then waits. The requester’s reply re-triggers the agent, which continues with the complete picture — the same ask-and-wait loop your triggered agents already use for clarifying questions.

For example, with a “User Onboarding” intent, an office manager’s email — “Hi, we’ve got someone new starting in the Bristol office” — comes back with one reply asking for the full name, start date, an access-template colleague, and the 2FA mobile number. When the manager answers, the agent picks the ticket back up with everything a technician (or your onboarding automation) needs.

​

What an intent contains

Tickets always land in the agent’s own configured destination — an intent is a pure intake script and doesn’t change where or how the ticket is filed.

​

Writing good questions

The Questions to ask field is free text read by the agent, so write it the way you’d brief a junior technician:

• List every detail your team needs to action the request without a follow-up — names, dates, devices, approvals.
• Note conditional questions inline: “If they need RDS access, ask which existing user to mirror.” Neo asks dependent questions one at a time.
• Don’t include details Neo can infer (the requester’s own name or company) — Neo already knows the conversation and the ticket, and only asks for what’s genuinely missing.

​

Scoping

Intents are tenant-level and cross-agent — you author one library of intents and assign each one to the surfaces, agents, and companies it should apply to. Agent and company scope work the same way, and leaving either empty means “all”:

• Agents — assign an intent to specific agents (e.g. only your “VIP Support” bot, or only the service-request board’s agent), or leave it empty to offer it on every agent of the selected surfaces. Authoring a common request like “New Starter” once and applying it everywhere beats duplicating it per agent.
• Companies — offer a different set to different clients: one client’s “New Starter” intent collects a 2FA number and an RDS-access answer, another’s doesn’t; a client on a phone system gets a “Ring Group Change” intent that others never see.

At runtime a request only ever meets the intents whose surface, agent scope, and company scope all include it — the surface it arrived on, the agent handling it, and the requester’s company.

​

Example: a new-starter intent in chat

Employee: Can you set up a new starter for me?

Bot: Happy to help. Please share the new joiner’s full name, their start date, an existing user to copy access from, and whether they need RDS access.

Employee: Jamie Rivera, starting 14 July, copy access from Alex Morgan, and yes to RDS.

Bot: Thanks — what’s the 2FA mobile number for Jamie?

Employee: 07700 900123

Bot: All set — I’ve raised ticket #4821 for Jamie Rivera’s onboarding and your IT team will take it from here.

The same intent with the Triggered agents surface handles the email version: a half-complete onboarding email becomes a ticket, the agent replies asking only for the missing 2FA number and start date, and the requester’s answer re-triggers the agent to finish intake.

​

Setting up intents

Your intents live in one place — add as many as you need, and edit or disable them any time.

​

Managing intents with the API

Intents are also fully manageable over Neo’s public API — list, read, create, update, and delete them under /public-api/intents — so you can author your intent library from your own scripts or provision it per client. See the API reference.

​

Related