The AI playbook
The wording, the questions, the refusals and the ticket changes that govern the AI when it files a service call.
The playbook is what the AI says when it files a service call, what it asks for when something is missing, and which tickets it must not work at all. It is at Settings, AI agents, Playbook, where the page is titled AI playbook.
Every part of it is yours to edit — the wording, the order the questions are asked in, and how many times a customer is asked before a person takes over. It ships with a working default, so the page is never blank.
Viewers see the real values, disabled rather than hidden. Only an admin can change the playbook, and the save bar says so.
The status line
A line above the editor states two facts.
- Whether your workspace has edited this playbook, or it is using the shipped default.
- Whether e-automate is connected, so these rules run on real service calls, or is not yet, in which case the playbook is saved and applies once it is.
Your words
Four pieces of wording.
| Field | What it is |
|---|---|
| Confirmation | The message the customer gets once a service call has been filed. |
| Opening | The first paragraph of the message that asks for missing information. Always included when something is missing. |
| Closing | The last paragraph, after the questions. |
| Signature | Added to the end of every message the AI sends on this workspace's tickets. |
Merge fields go in double braces, like {{ticket.requester.firstname}}. The
reference panel beside the editor lists every field this helpdesk can fill.
A blank is never sent
A merge field a ticket cannot fill is never sent blank and never shown as raw braces. The message is held back and the ticket goes to a person instead — unless you have given a stand-in for that field.
Status updates to the customer
When a service call moves in e-automate, the customer is told without having to ring and ask. There are five transitions, each with its own switch and its own wording:
- Scheduled — the call has a due date, or it moved. Sent when e-automate first gives the call a due date, and again if that date changes.
- On the way — e-automate has dispatched the call.
- Arrived — the technician is on site. This is the message customers ring up to ask for.
- On hold — the call is parked. The reason is a dealer code, so it is not in the shipped wording.
- Closed — e-automate has completed the call. Sent once, when a close date first appears.
Every fact these can name comes from e-automate itself. There is no merge field for an ETA, because e-automate has no ETA; anything you promise about timing is your own wording.
What a service call needs before it can be filed
A list of required fields, in the order the questions are asked. One paragraph per missing item, in this sequence — items already on the ticket are skipped entirely. Rows move up and down, and each carries:
- What we ask for — the paragraph the customer reads.
- Help article link (optional) — added under the paragraph. Useful where a customer has to go and look at the machine.
- Already satisfied when the ticket has — one condition per line. Join two
with
+to require both. If any line is satisfied, the customer is not asked.
Tickets the AI must not work
Exclusion rules are checked first, before anything else and before e-automate is touched. On a match the service call is not placed, the ticket is unassigned so a person picks it up, and the reason you write is what they are told. The first matching rule wins.
Each rule has a name, a field to test, a pattern, a reason, and its own enable
switch. The pattern is a regular expression — ^X means "starts with X", and
(?i) in front ignores capitals. Matching is exact; there is no near-match.
Which call type the AI files under
Call-type rules are checked in order, top to bottom, and the first rule that matches decides. The call type is what routes the job to the right technician in e-automate, so the order here is the order your board gets sorted by.
Each rule pairs a When this field with a Matches regular expression, and then sets File as, a Problem code and a Ticket priority. Rules can be reordered, disabled and removed.
What the AI does to the ticket
This card is applied to the helpdesk's own ticket, never to e-automate.
| Setting | What it does |
|---|---|
| Ticket type | Set on every ticket the AI works. |
| Your service call type | Free text, because this is a value in your e-automate and not one of ours. |
| Agent that owns the ticket once the call is placed | Recorded beside the human assignee, never instead of it — an empty assignee still means a person should pick this up. |
| Let the AI move the ticket's status | Off by its own switch, because moving a status is the part that can undo work a person has already done. Two statuses are set: one when the AI has asked the customer for something it needs, and one once e-automate has accepted the call and given it a number. |
The type and the agent are recorded whenever the AI works a call. Moving the status is separate, and deliberately so.
How many times a customer is asked
After this many unanswered asks, the ticket is unassigned from the AI so a person can take it. Zero means hand it over the moment anything is missing; one means ask once, then hand over.
Stand-ins for missing values
A list of fallbacks, one per merge field. If you give a stand-in, it is used. If you do not, the message is held back and the ticket goes to a person instead.
The preview
A preview is pinned beside the editor and renders the current draft, not the saved version, against a real ticket — the newest one, or an ID you type. It reports three things the form cannot: which required fields that ticket is missing, which exclusion rule fires on it, and which merge fields would block the send. It also shows the rendered missing-information message and the confirmation that would be filed.
Use it. The two ways one of these templates goes wrong are both invisible in a form: a merge field your tickets never fill looks fine until it refuses to send, and an exclusion pattern meant to catch one equipment ID can silently match every one of them.
Saving
Save playbook commits the draft; the button is inactive until something has changed. Reset to the shipped default puts the shipped wording and rules back into the draft, and it is still a draft until you save.