Start with the ticket, not the call. The Autotask Ticket entity marks 6 of its 74 fields as required and 1 of those is read-only, so 5 must come from your agent: companyID, dueDateTime, priority, status and title. Build that payload on day one, prove your PSA accepts it, then give it a phone number.
Almost everything written about AI voice triage for managed service providers is written by somebody selling it. This is the sequence an MSP works through instead: which PSA fields the agent must produce, where ConnectWise PSA, HaloPSA and Autotask each document them, what the agent must never do on a call, and what it costs in hours once the demo is over.
What happens when someone calls my helpdesk at 2am?
On most small MSP desks one of three things happens: voicemail read at 7am, an on-call engineer woken for something that could have waited, or an answering service writing a paragraph somebody retypes into the PSA. All three produce prose, and prose is not a ticket. Whether to keep paying humans to answer at all is a separate question, priced on Australian rate cards in our comparison of a human answering service against an AI receptionist; this page starts after that decision.
The rule worth remembering has a handle: ticket or transfer. Every after-hours call ends in one of two states — a ticket ID returned by the PSA, or a live human on the line. Never a voicemail, never a note. Everything else is ordered by that, because you cannot design the conversation until you know what a valid ticket requires.
Day one: build the ticket payload before you write a word of script
The first real action is not choosing a voice vendor. It is creating one ticket through your own PSA API by hand, smallest payload the platform accepts, against a real client record.
- Write down what is mandatory. Not what the UI asks for — what the API rejects. The two differ, and the API is the contract your agent lives under.
- Pull priority values at runtime. Autotask priority is an integer backed by a per-instance picklist, read by a GET to the
/entityInformation/fieldsendpoint of the entity; each picklistValues item carries value, label, isDefaultValue, sortOrder, parentValue, isActive and isSystem. Hardcoding “priority 2 means high” is how a pilot files every outage as a routine request. - Decide your contact-match key and your unmatched path. Caller line identity is a hint, not an identity, and unmatched numbers will be most of your calls.
- Have the on-call engineer work that ticket cold. If they ring the caller back to find out which site they are at, the payload is short a field. Add it and repeat.
- Only now attach the voice agent, whose whole job is to fill the payload you just proved.
Day one is over when a ticket you created through the API has been worked to closure by a human who never spoke to you.
The PSA ticket-field mapping table
Every cell was read on 18 September 2026 in the named vendor documentation, not in an integration listing or a blog post. A blank cell means the documentation was not readable without an account, and the row says so rather than borrowing the value elsewhere.
| What the agent needs to know | ConnectWise PSA | HaloPSA | Autotask (Kaseya) |
|---|---|---|---|
| Documentation read | Not available. The ConnectWise Developer Network product and REST pages return a sign-in form, and the public product documentation path redirects to an authentication handler. | Halo API Documentation, Tickets resource, published by Halo Service Solutions and served from the vendor instance at halo.haloservicedesk.com. | Autotask REST API developer help, Tickets entity page, served from ww1.autotask.net. |
| Create endpoint | — | POST /Tickets. Documented as adding or updating one or more tickets: if id is included it updates, if not included it creates. | POST to the Tickets entity of the REST API. |
| Fields the documentation marks required on create | — | None enumerated. The POST method is documented with an empty parameter table, so the required set is not published. | companyID, dueDateTime, priority, status, title. Six rows in the 74-row field table carry the required marker; the sixth is id, which is also marked read-only. |
| Documented conditions that change what is required | — | — | dueDateTime is required unless the supplied ticket category, or the user default ticket category, has both Due Date and Due Time configured. queueID is required or not according to the ticket category Queue is Required setting. billingCodeID is required on create and update if the Autotask system setting that requires a Work Type on a ticket is enabled. |
| Priority field | — | priority_id, integer, on the ticket object. | priority, integer, flagged as a picklist. On create the value must be an active priority. |
| Priority enumeration | — | Not published in the API documentation. The documentation resource index lists 21 resources and 43 endpoint routes, and a priority resource is not among them, though a Status resource is. | Not fixed. Retrieved per instance from /entityInformation/fields, where each value carries label, isActive and isSystem. |
| Contact-match key | — | user_id on the ticket, with user_email and reportedby also on the object. Contacts are found through GET /Users, which documents search, search_phonenumbers (filter by users with a phone number like your search), client_id and site_id filters. | contactID, not itself required, and constrained: Contact.companyID must equal ticket.companyID or the parentCompanyID of ticket.companyID. |
| Free-text fields the agent fills | — | summary and details on the ticket object. | title, string (255); description, string (8000). |
| Silent default worth knowing | — | — | A ticket with no ticketType supplied is set automatically to Service Request. |
Two findings matter more than the field names. Neither Halo nor Autotask publishes a priority enumeration you can hardcode, so the mapping is built per tenant. And ConnectWise PSA field requirements could not be verified without an account — if you run ConnectWise, read the Service Tickets endpoint inside the Developer Network yourself, and do not take a field list from anyone who has not.
What the agent must capture before the ticket is valid
The mandatory API fields are the floor, not the target: a ticket that satisfies the API and still forces a callback has failed. This list is the specification your conversation design has to hit. Our note on what a handoff packet must carry when an AI agent passes a conversation to a person covers the human-to-human side; a ticket queue is less forgiving, because it cannot ask a follow-up question.
- A matched contact ID, or an explicit unmatched flag. A caller name typed into the description is not a match. Scope the search to the client; if nothing matches, set a flag the queue can filter on.
- The client and the site. Autotask will not accept a ticket without companyID; Halo carries client_id and site_id. Multi-site clients are where triage quietly goes wrong.
- A title naming the system and the symptom, inside the 255-character limit Autotask documents, written to sort usefully in a queue view.
- Scope: how many people are affected, and is there a workaround. These two answers decide priority and escalation.
- A confirmed callback number, plus whether the caller is at the affected device.
- A priority drawn from the live picklist, never a constant in your code.
- A transcript or recording reference, so the engineer can check what was said rather than trusting a summary.
The Never-By-Voice Six
Here is the failure the vendor pages skip, and it is not a quality problem. A voice agent cannot authenticate a caller: it can recognise a number and hear a confident voice, and neither is authentication. That matters because the helpdesk password reset is a known attack path, not a hypothetical one.
In joint advisory AA23-320A, originally released 16 November 2023 and last revised 29 July 2025, CISA, the FBI and international partners describe attackers posing as company IT or helpdesk staff on phone calls to obtain credentials, and calling helpdesk personnel to have passwords reset and MFA tokens transferred. CISA countermeasure CM0033, Reset User Account Passwords, version 1.0 dated 14 March 2025, lists as key preparation elements that a means of attestation is defined to verify the veracity of users requiring a manual password reset, and that the environment is configured to support self-service password reset for users. Keeping the manual path rare is our inference from that pair, not a CISA instruction.
NIST says why a phone call cannot carry that attestation. NIST Special Publication 800-63B, dated 26 August 2025, recognises four classes of account recovery method — saved recovery codes, issued recovery codes, recovery contacts and repeated identity proofing — and to recover an account that can authenticate at AAL2 it requires one of three: two recovery codes obtained by different methods, one recovery code plus a single-factor authenticator bound to the account, or repeated identity proofing. A caller who sounds right is not on that list.
So the framework needs a hard list. The Never-By-Voice Six: the agent may log any of these as a ticket and route it, and may never perform it.
| Request | What the agent does instead |
|---|---|
| Password reset or unlock | Creates the ticket, then directs the caller to the self-service reset route. Never resets, never reads a temporary password aloud. |
| MFA re-enrolment, device swap or bypass code | Ticket only, routed to the verified-identity process your MSP already runs for that client. |
| Changing a contact email address, phone number or named-contact status | Ticket only. Changing the recovery address is the step that makes the next reset succeed. |
| Granting, elevating or restoring access rights | Ticket only, flagged for an engineer with authority over that client tenant. |
| Disabling or bypassing a security control | Ticket only, and escalate immediately rather than at the morning triage. |
| Anything that moves money or data: payment details, mailbox forwarding rules, bulk export | Ticket only, escalate, and record the request verbatim. |
One design detail decides whether the list works or merely exists. The refusal has to be identical for everyone. An agent that says it cannot verify you today but could with a ticket reference has just taught the next caller what to bring. Write one refusal, use it for the legitimate user and the impostor alike, and log the attempt either way. Topics that are off limits regardless of model confidence are the same discipline as escalation thresholds for an AI agent: the topic match outranks the confidence score.
Escalate now, or leave it until morning
The test that decides is the pair of questions above: how many are affected, and is there a workaround. Severity words from the caller do not decide it, because every caller at 2am is having an emergency.
| Situation | Action in the next 15 minutes | What decides it |
|---|---|---|
| Nobody at the client can work: line of business application, connectivity or authentication down | Page the on-call engineer and stay on the line until acknowledged | Multiple users, no workaround |
| One user cannot work and no workaround exists, on a contract with after-hours cover | Page, unless the contract says business hours | Contract terms, checked against the client record |
| Caller reports a suspicious email, unexpected MFA prompts, encrypted files or a ransom note | Page immediately, action nothing, change nothing | Any security signal, regardless of user count |
| Credential or MFA request of any kind | Ticket, route to the verified-identity process, do not page | Never-By-Voice Six |
| Alert echoed by your RMM and affecting a server, backup or monitoring path | Page, with the correlated alert referenced in the ticket | Corroboration by a second system |
| Single-user nuisance: printer, one mailbox rule, an expiry reminder | Ticket at the client default priority for the morning queue | One user with a workaround |
Below the outage threshold, wake nobody. An MSP that pages on every after-hours call gets an on-call rota that quits.
What this actually costs to run
The arithmetic, with every input written out as an assumption you can substitute. None of these figures is a measurement from a live deployment; they are stated so the model is auditable. Assume 40 client companies and one after-hours call per client per month, so 40 calls a month.
- Build: roughly 4 to 8 hours for an engineer who can read API documentation, to map fields, pull picklists and get a ticket accepted end to end.
- Per-client setup: about 15 minutes each for the client record, sites and after-hours contract rule. At 40 clients, 10 hours once.
- Review, first month: every ticket, at an assumed 4 minutes each. 40 tickets is 160 minutes, near enough 2.7 hours.
- Review, steady state: escalations and unmatched callers only. Assume 15 per cent of calls: 6 tickets at 4 minutes is 24 minutes a month.
- Drift: every new client, PSA category change and new priority value is a mapping change. Budget it as maintenance, not a project.
- Telephony is per-minute. On its US voice pricing page, read 18 September 2026, Twilio publishes US$0.0085 per minute to receive a call on a local number plus US$1.15 per month for the number, and US$0.0025 per minute for call recording. Model usage is separate and set by whichever speech and language vendors you pick, so price those on their own pages on the day you build the model.
The skill requirement is what gets underestimated: this is an integration against a ticketing API, a per-tenant configuration problem and a security control, not a prompt-writing exercise. Substitute your own call volume and hourly cost, then compare against what the current after-hours arrangement costs including the mornings spent retyping.
How that write path is built — vendor connector, middleware, or code against the REST API with your own retries — is the decision set out in native connector, Zapier or direct API for agent write-back, and the broader capability set sits in AI customer support agents handling tier-one resolution around the clock. Zian runs a niched IT Technical Support Agent in that digital team, and its published integration list is HubSpot, Salesforce, HighLevel and Zapier plus API access — no PSA is on it, so a ConnectWise, Halo or Autotask write path is built over the API rather than switched on. Zian also supports private model deployment on customer infrastructure, the relevant option for an MSP that cannot send client data to a shared cloud.
The finish state, and the test that proves you reached it
You are finished when five scripted calls produce five tickets your PSA accepted, and an engineer who did not hear the calls works all five without ringing anybody back:
- One known contact calling from a number on their record, reporting a single-user issue.
- One caller from an unknown number at a known client, reporting a site-wide outage.
- One caller asking for a password reset.
- One caller reporting a suspicious email and encrypted files.
- One caller who gives a client name you do not have.
Pass conditions: five tickets created, zero fields edited by a human before work began, outage and security calls paged inside your stated window, the reset call logged and not actioned, the unknown client routed to a human rather than filed. Keep the scripts and re-run them after every mapping change — the same discipline as testing an AI voice agent before it goes live.
Frequently asked questions
Can an AI voice agent reset a password for a caller?
No. It can create the ticket and point the caller at self service, and it must not perform the reset. NIST Special Publication 800-63B, dated 26 August 2025, recognises four classes of account recovery method and requires, for an account at AAL2, either two recovery codes obtained by different methods, one recovery code plus a bound single-factor authenticator, or repeated identity proofing. A voice call satisfies none of them.
Which fields must the agent fill for Autotask to accept a ticket?
Five that you supply: companyID, dueDateTime, priority, status and title. The Autotask Ticket field table marks six fields as required, but the sixth is id, which is also marked read only. The dueDateTime requirement is waived when the supplied ticket category, or the user default ticket category, already carries both a due date and a due time.
Does HaloPSA publish the required fields for creating a ticket?
Not in its API documentation, as read on 18 September 2026. The POST Tickets method is documented as adding or updating tickets, with an empty parameter table, so no required set is enumerated. The ticket object itself documents summary, details, tickettype_id, priority_id, client_id, site_id and user_id, and the documented resource index lists 21 resources with no priority resource among them.
Why can I not find the ConnectWise PSA ticket field list?
Because it is behind a sign in. As at 18 September 2026 the ConnectWise Developer Network product and REST pages return a login form, and the public documentation path redirects to an authentication handler. Read the Service Tickets endpoint inside your own account rather than taking a field list from a third party.
How does the agent decide whether to wake the on call engineer?
Two questions decide it: how many people are affected, and whether a workaround exists. Multiple users with no workaround pages immediately. One user with a workaround becomes a morning ticket. Any security signal pages regardless of how many people are affected.
Where to go next
Zian AI builds autonomous voice and multichannel agents, including a niched IT Technical Support Agent, and is currently in partnership-application beta. Apply For Partnership.