Key takeaway
Define routine topics, approved knowledge and escalation before launch. Measure correct resolution and useful handoffs, not just ticket closure.
Keep the customer’s familiar intake channel
An AI-assisted workflow can begin in the customer portal and chat window they already use. The agent clarifies the issue, replies from approved service material and retains the steps taken. The customer does not need to find a separate bot site or learn another intake process. If it cannot resolve the issue, it creates a ticket and passes the conversation into the queue as context so the technician does not start over.
Receive the request
Capture the customer’s language, tenant, service and affected user.
Offer a safe first step
Provide a relevant approved knowledge-base step and ask what happened.
If unresolved, pass the context
Attach the conversation, attempted steps and open question to a ticket for the right queue.
Set safe boundaries for automated resolution
Routine information requests and repeat diagnostics may suit automation; account unlocks, disabling MFA, changing privileges, deleting data and closing a security incident can have greater impact. For each category, state what the agent may explain, what it may check and which action requires technician approval. Verify the user through an approved process. Do not let the agent reset a password or grant access before identity and authority are confirmed.
| Request type | Initial response | Control |
|---|---|---|
| Service information | Provide the approved guidance | Escalate if the guidance does not help |
| Repeat diagnostic | Gather details and suggest a safe step | Hand off if risk or service impact increases |
| Access or data change | Clarify the request and prepare it for review | Require identity checks and human approval |
Protect data boundaries across tenants
One MSP agent may serve several customers, so tenant and knowledge-base boundaries are core design choices. Check which articles, service terms, device details and accounts are visible for each customer; never use one customer’s ticket as another customer’s answer source. Give the agent only the read and action permissions it needs. Keep an activity record linking customer, ticket, agent response, escalation and technician decision, while excluding secret passwords and authentication codes from summaries.
Measure resolution and handoff quality
Counting AI replies or closed tickets can overstate success. Measure the share of eligible requests resolved with an approved answer, reopened tickets, correct handoffs, technician time spent reconstructing context, time from first response to resolution and repeat requests. Compare results by customer and service. Review how safely the agent advances after-hours requests; an immediate reply is not the same as a resolution.
Correct resolution
Does the answer match service guidance, and does the customer confirm the issue is resolved?
Useful handoff
Does the ticket include customer, impact, attempted steps and the open question?
Repeat work
Does the customer reopen the issue, or does the technician have to rebuild context?
Example: an after-hours account lockout
At night, a user reports through the portal that they cannot sign in. The agent identifies the customer and user, asks for the error text and when the issue began. If an approved guide applies, it offers safe recovery steps without asking for a password or one-time code. It does not unlock the account when identity verification is required; it routes a prioritised ticket with the full conversation to the on-call technician. In the morning, the team reviews routing, missing context, time to resolution and repeat contact.