The demo is over. Now comes ownership.
A successful pilot proves something can work. It does not prove anyone can operate, support, secure, or justify it six months from now.
Before moving from pilot to production, determine who owns it, who supports it, what it costs, and what happens when it fails.
Before we scale a pilot
Hand the pilot to the people expected to use and support it. Test normal work and failure cases, then decide whether the benefit is worth the continuing effort and risk.
A pilot may use selected inputs, a closely supervised process and someone who knows exactly when to step in. That can be appropriate for learning. It does not establish what will happen on an ordinary working day.
Find the work the demo did not show
Write down everything people did around the tool: preparing information, fixing access, correcting answers, approving actions and recovering failures. Those activities belong in the cost and support plan. They should not disappear when the pilot is presented to leadership.
What looks like automation during a demonstration often depends on manual effort that was never counted. A successful rollout includes the hidden work, not just the visible outcome.
Test the handover, not just the output
Ask a representative user to complete the task without the pilot team coaching each step. Use approved inputs similar to normal work. Observe where the user gets stuck and who would receive the support request.
Then introduce the cases that change the recommendation: missing information, contradictory records, unavailable dependencies and a request the workflow should not carry out. Define which cases stop, which go to a reviewer and which may continue.
The goal is not to prove the workflow succeeds. The goal is to understand how it behaves when it doesn’t.
Revalidate the business case
Many pilots succeed because they receive focused attention, executive sponsorship and access to skilled people. Six months later those conditions may no longer exist.
Before expanding the solution, confirm that the original business problem still exists and that the expected value can be measured. Consider:
- What cost, delay or risk was the pilot expected to reduce?
- Has the process changed since the pilot began?
- How will success be measured after rollout?
- Is anyone still prepared to sponsor the effort?
- Would the business fund the solution if starting the evaluation today?
A pilot that demonstrates technical success but delivers little operational value should not automatically move forward.
Check whether a failure becomes a real-world action
Illustrative example, not a client case. A pilot drafts CRM follow-up recommendations. That is one level of risk. Allowing it to update opportunities or send customer messages changes the consequences of an error.
Test stale records and conflicting meeting notes before considering those actions. Decide who authorizes a change, how it is recorded and how the team would recover from a mistake.
Keep drafting and action permissions separate until the business has explicitly accepted the difference.
Agree who carries the responsibility
| Role | Responsibility |
|---|---|
| Business owner | Accepts the result and decides whether the workflow is worth continuing. |
| Information owner | Approves the sources, access and handling arrangements. |
| Reviewer | Checks outputs or actions that require human judgment. |
| Support owner | Handles access failures, broken connections and user questions. |
| Budget owner | Watches recurring charges and the effort required to complete the work. |
| Change owner | Triggers review when sources, instructions, tools or policies change. |
These responsibilities may sit with the same person in a small operation. They still need to be explicit. Check the actual tool and connected-service terms; do not assume that one approval covers every component.
Ask for evidence in four control areas
The customer-facing Agent 365 security reference groups the review around identity, threat monitoring, information protection and the agent inventory. Those are useful questions even before deciding which products should provide the controls.
| Review area | What to establish | Evidence to request |
|---|---|---|
| Identity and access | Whose identity performs each action, what permissions it has and how access is removed. | An access review and a test showing that an unauthorized resource remains inaccessible. |
| Threat monitoring | Who sees suspicious activity and who responds. | A controlled test traced through the monitoring and incident process. |
| Information protection | What the agent can read, return and send. | Tests using restricted information and blocked destinations. |
| Inventory and continuing approval | Who owns the agent and why it still exists. | A current inventory record, operational owner and review date. |
Check the controls on both sides of an action. The agent’s instructions may say not to access a resource, but the resource should still enforce its own authorization. Guidance in a prompt is not a replacement for a tested access boundary.
Do not accept a dashboard screenshot as proof that these controls work together. Trace one permitted action and one blocked action through the environment. Record which team supplies each piece of evidence and which gaps remain.
Watch what changes after approval
Production environments do not stay still. Data sources change. Business processes change. Policies change. Vendors change. Models change. A workflow approved six months ago may no longer operate under the same conditions today.
Changes that should trigger review include:
- New data sources
- New actions
- Additional permissions
- New external services
- Changes to prompts or instructions
- Regulatory or policy updates
- Significant usage growth
Many production issues start with a change that nobody considered significant at the time.
Give the business a way to stop
Decide how to pause the workflow, who can do it and how essential work continues. Agree what failure or cost increase triggers a review. An old process that nobody can restart is not a useful fallback.
Document:
- Who can disable the workflow
- How users are notified
- What work continues manually
- How data is preserved
- What conditions trigger restart
The next step can be a limited rollout, a revised pilot or no further investment. State what the test established and what remains unresolved. Stopping can be a sound result when the alternative is putting unsupported work into production.
Final thought
A useful pilot leaves the business with more than a demonstration. It leaves the people responsible for the service able to explain:
- How it works
- What it costs
- Who owns it
- What controls exist
- How it is supported
- What happens when it fails
- How it can be stopped
If those questions cannot be answered clearly, the pilot is not ready to become a production service.
Need help applying this?
See the related service or talk with us about your situation.