Skip to main content
Start with one recurring request and follow it all the way to a verified result and customer reply. A useful pilot shows how much work the agent completes, where your team is still needed, and what each resolved case costs.

​
Choose the first tickets

Pick a request you handle often, with a known procedure and a result you can check. Start with one customer or service category. Filter intake in your help desk or the integration that sends requests to the agent, and test that out-of-scope tickets stay in your normal queue. Workflow instructions explain the job; they do not replace intake filters or access controls. An information request is a useful first test: “Does this site have a working backup internet connection?” The agent should inspect the permitted management system, distinguish a configured failover policy from a usable backup link, and reply with its findings. That request does not authorize a configuration change. Once that works, add a bounded change with approval and a live verification step. Use Run the full support loop to build the workflow.

​
Bring these to onboarding

Confirm agent eligibility and enablement, then prepare: Check the exact operation, not just the integration’s name. Reading a ticket, sending a reply, changing a service, and controlling a remote desktop are different capabilities. Production workers use supported cloud tools; desktop access does not transfer to them. Confirm your path in Connectors and MCP and the current availability limits.

​
Test work that crosses systems

A mailbox-capacity request illustrates a workflow with both technical work and business decisions. Adapt this pattern only after confirming the required mail-service and supplier operations are available:
  1. Read the ticket and check the mailbox’s live state in the correct customer tenant.
  2. Prepare the available options and ask the customer’s current authorized decision-maker to choose. Record their decision before any purchase or change.
  3. Perform the permitted supplier or licensing operation through its configured connection, with the required execution approval. If that operation is unavailable, assign it to a person.
  4. Wait for provisioning, then check that the entitlement is available before applying the approved change.
  5. Verify the result, update the intended recipients, and close or escalate the ticket with evidence.
This is a workflow design, not a preconfigured mailbox or supplier integration. Customer authorization and execution approval are separate. A task can wait for a person or a later check without requiring the agent to keep a desktop open.

​
Agree what success means

Use the same ticket category and reporting period when comparing the pilot with your existing process. Use the agent’s Outcomes and Activity alongside the help desk and target-system records. A completed run alone does not prove the ticket was resolved. See Usage and billing for consumption and commercial questions.

​
Expand when the evidence supports it

Before adding another customer or ticket category, test a rejected change, an ambiguous customer identity, an unavailable connector, a missing approver, and an unsuccessful fix. Check that each case reaches the right person with useful evidence and an accurate customer update. Expand intake, tools, and unattended actions deliberately. Keep review enabled for new operations until you have checked their targets, side effects, and verification. Learning from past tickets does not grant additional permissions.