> ## Documentation Index
> Fetch the complete documentation index at: https://altostrat.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Plan a support-agent pilot

> Prove value on a small set of real tickets, with clear access, approvals, success criteria, and a path to expand.

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](https://altostrat.io/docs/studio/en/support-loop.md) to build the workflow.

## Bring these to onboarding

Confirm [agent eligibility and enablement](https://altostrat.io/docs/studio/en/digital-workers.md#before-you-start), then prepare:

| Bring | Decide together |
| - | - |
| Representative tickets | Which requests enter the pilot, which stay with your team, and what a correct resolution looks like. |
| Existing runbooks and customer rules | The approved method, naming conventions, maintenance windows, and exceptions. See [existing knowledge bases](https://altostrat.io/docs/studio/en/org-brain.md#use-your-existing-knowledge-base). |
| Systems and accounts | The ticketing and operational APIs needed for each step, the customer/tenant mapping, and credentials scoped to the agent's work. |
| Decision owners | Who can approve a customer change or purchase, who reviews execution in Studio, and who covers an absent approver. |
| Communication rules | Internal notes versus public replies, permitted recipients, and when a person must contact the customer. |
| Baseline and budget | Current handling time, ticket volume, resolution quality, and the usage allowance you want to evaluate. |

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](https://altostrat.io/docs/studio/en/connectors-and-mcp.md) and the [current availability limits](https://altostrat.io/docs/studio/en/ai-safety/known-limits-and-roadmap.md#org-brain-and-worker-availability).

## 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](https://altostrat.io/docs/studio/en/support-loop.md#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.

| Measure | Count or inspect |
| - | - |
| Verified resolution rate | Eligible tickets with a confirmed result and customer update, divided by all eligible tickets handled. Review reopened or incorrectly closed cases separately. |
| Human effort | Technician time spent answering questions, approving work, completing handoffs, and correcting results. |
| Time to resolution | End-to-end elapsed time, including waits for people and external systems. |
| Cost per verified resolution | Recorded agent usage for the pilot, including failed attempts and retries, divided by verified resolutions. Include third-party costs in your overall comparison. |

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](https://altostrat.io/docs/studio/en/usage-and-billing.md#estimate-a-support-workload) 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.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.