PRODUCT · AVA AIX VIRTUAL ASSISTANT AUTOTASK PSA IN PRODUCTION
Product · AVA
The AI chat your clients use to reach your engineers.
AVA is the web chat we built for our own MSP. Clients message us in plain English. AVA writes the Autotask ticket, classifies it, assigns the right engineer, and lets us log time, add internal and client-facing notes, and update status without ever leaving the chat.
What it is
A real chat, with the right ticket already written.
AVA is the layer between a client's question and an engineer's answer. The client gets a conversation. The engineer gets a fully-formed Autotask ticket and a running summary. The PSA gets every action logged, automatically.
AVA started as the helpdesk chat surface we wanted for our own MSP. We were tired of two things at once: clients filing terse, low-context tickets through an email-shaped form, and engineers re-typing the same triage notes three times across three tools. AVA is the layer that makes both problems disappear.
It runs as a public web chat on the client's side and as an engineer console on ours, with deep Autotask PSA integration in between. We built it for Autotask first because that is the PSA we operate. The architecture generalizes to ConnectWise Manage and HaloPSA, which is a roadmap conversation, not a v1 feature.
What AVA does
Nine things, deliberately scoped.
Every capability earns its place against one test: does it eliminate a step the engineer or the client would otherwise repeat? If yes, it ships. If no, it stays out.
-
Web chat for clients
AVA lives on a public web surface. Your customers open the chat, type the problem, and start a real conversation with a real engineer. No login wall, no ticket form, no portal training.
-
Autotask ticket creation, automatic
Every chat session writes an Autotask PSA ticket on the first message. Title, description, contact, configuration item, and source channel are filled in from the conversation. The ticket exists by the time the engineer says hello.
-
Auto-categorization
AVA classifies the issue from the opening message. Queue, sub-issue, severity, billable vs. covered, using a small classifier fine-tuned on your historical ticket corpus. Wrong calls are one click to override.
-
Auto-assignment to the right engineer
Routing reads the live on-call schedule, queue depth, skill tags on the issue category, and who is already in another chat. The session lands with the engineer who can resolve it fastest, not the one whose name comes up first in a round-robin.
-
Transfer chats between engineers
Hand a session to a teammate in one step. Context, ticket history, and the live conversation move with it. The client sees a one-line handoff message. The receiving engineer sees the full thread plus AVA's running summary.
-
Time entries from the chat surface
When the call wraps, AVA drafts the time entry in your standard format: billable flag, work type, summary derived from the conversation. One click posts it to the Autotask ticket. End-of-day time-entry backlog goes away.
-
Internal and client-facing notes
Two note streams on every ticket. Internal notes (architecture, root cause, what to watch next time) stay with the engineer. External notes (status updates, next-step ETAs) are visible to the client in their own chat thread. Same composer, one toggle.
-
Status updates direct from chat
Resolve, escalate, on-hold, waiting-on-customer. Flip the status from the chat sidebar and AVA writes it back to Autotask in real time. The chat thread reflects it. Reporting reflects it. Nothing is reentered.
-
Knowledge retrieval before the engineer types
AVA searches your closed-ticket corpus and KB articles on every new chat, surfaces the top three matches inline, and lets the engineer cite them with one click. Faster first response, fewer reinvented resolutions.
How it's built
Built on retrieval, not memorization.
Under the hood, AVA is a RAG system coupled to a constrained set of write tools. Every model response is grounded in retrieved context: the client's ticket history, similar past tickets, your KB articles, and the live Autotask state of the active ticket. We do not ask the model to remember facts about your environment. We ask it to reason over facts we hand it.
Tool use is intentionally narrow: search the ticket corpus, fetch a specific ticket, fetch a user's history, draft a time entry, post a time entry, post a note, update ticket status, transfer a chat. That is the whole surface. Every candidate tool was gated with the same question: does this decide something an engineer would otherwise decide, and is the cost of being wrong bounded? Most candidates did not pass.
The eval harness is the part of the build that does not demo well and is the only reason AVA is in production. Every change runs against a regression set drawn from real historical tickets. See Anthropic's evaluation guidance and the OpenAI evals cookbook for the patterns we follow.
Live console
Inside the agent
14:02:11 chat.open client="acme corp" contact="j.harper" 14:02:11 intake msg: "VPN drops every morning around 8:30" 14:02:11 ticket.write autotask #4092 created queue=network 14:02:12 classify category=vpn_outage conf=0.94 14:02:12 retrieve tickets:[#3811, #3645] kb:[A19, A22] 14:02:13 route on-call=mhassan skill=vpn load=2 14:02:13 assign autotask #4092 → mhassan 14:02:14 draft.reply cite=[#3811, A19] tokens=4,302 14:02:14 status.set autotask #4092 → in_progress ───────────────────────────────────────────────────────────── chat-open → engineer-assigned: 2.6s cost: $0.011
For other MSPs
Licensable, with an opinionated onboarding.
AVA is in production with our team and licensable to other Autotask PSA shops. If you run an MSP and want the chat surface, the Autotask integration plumbing, and the eval harness without the months we spent building them, the discovery call is the right starting point.
The conversation we will have on the call is honest. We look at your ticket shape, your queue structure, your KB hygiene, and we tell you whether AVA fits as-is, whether it fits with a small custom layer, or whether your shop is structurally far enough from ours that a custom build is the better answer. Sometimes the answer is the third one. We say so.
Stay close