The tool usually arrives before the operating model
At dotSolved, I often get involved in Claude rollouts after the licenses have been provisioned. People have tried a few things and want to connect business data next. That is when the unresolved questions become obvious: who approved access to the finance warehouse, which decision are we helping with, and who will check the answer? I would rather settle those questions while the team is still choosing its first workflow.
Those decisions are simple to state and surprisingly hard to settle: which business decision the pilot supports, what each participant is allowed to see, and what evidence will tell reviewers an answer is good enough. I have seen the same pattern at a community bank piloting its first assistant, a health benefits company preparing for HIPAA review and a technology company with thousands of engineers. Size changes the paperwork. It does not change the order of operations.
Decision one: name the business decision, not the aspiration
A Claude pilot should earn its place inside a decision someone already makes. “Help finance work faster” is an aspiration. “Help the collections manager decide which disputed invoices need intervention before Friday” names a person, a deadline and an observable outcome. That sentence tells you what data you need, which questions to test and who will judge the result.
Write a one-page decision brief before anyone draws integration architecture. Capture the current process, who asks, who reviews and who can act. Describe what a wrong recommendation would cost. A weekly prioritization meeting and a payment release may touch the same records, but they should never inherit the same approval path.
Name what stays outside the pilot, too. A collections assistant can summarize overdue balances while customer outreach stays with the account owner. That boundary gives users something useful without quietly converting an information experiment into an automated business process.
Decision two: set access before the first user logs in
Security first is the lesson I repeat most from Claude deployments. Identity, permissions and data boundaries belong in place before anyone signs in, because retrofitting them after enthusiasm spreads is slow and political. A connector that can reach a source does not mean every employee may read every record in it. System connectivity and business authority are separate questions.
In banking, I learned to test permissions with specific requests. Can a regional manager see another region’s balances? Can an analyst open an individual’s compensation? What happens when a participant changes teams during the pilot? The answers should be visible in the access configuration and in the evaluation results. A written policy helps reviewers understand the intent; the test shows whether the implementation follows it.
Start narrower than the ambition. Limiting the period, business unit and fields reduces review effort and makes surprises easier to diagnose. Record that limitation explicitly so a successful narrow pilot never becomes an unsupported claim of enterprise readiness.
Decision three: agree what counts as evidence
A confident paragraph is not evidence. For each representative question, assemble the reference answer, the source records or approved report behind it, the metric definition and the reporting cutoff. Include cases where asking for clarification is the correct response.
Suppose two reports show different overdue balances because one excludes disputed invoices. The evaluation should reward an assistant that surfaces the definition mismatch and penalize one that invents a fluent reconciliation. Reviewers need a shared rubric covering correctness, evidence, permission handling and usefulness for the actual decision. It is the same discipline model risk teams apply in banking and quality teams apply to clinical reporting in healthcare.
Keep connectivity and business acceptance separate. A working connection proves a request reaches a service. It does not prove the answer means the right thing, that access is appropriate or that the workflow improved. Each conclusion needs its own evidence.
Turn readiness into a bounded ninety-day plan
Close the readiness discussion by naming a business owner, a data owner and a technical owner. Agree the initial question set, who approves reference answers and when results will be reviewed. Write down stop conditions, such as unexplained permission failures or persistent disagreement on a core metric. Then measure in weeks. A well-scoped 90-day pilot with clear metrics settles questions that months of product presentations never will.
Do not turn the first meeting into a contest over a maturity score. Its purpose is to surface decisions that would otherwise be made implicitly during implementation. A team with unresolved definitions can still progress by running a definition workshop. A team with clean reports and unclear ownership may need an operating agreement first.
For a CIO or CFO weighing the next funding request, those three decisions separate a persuasive demonstration from a pilot worth backing: the decision to support, the boundary to preserve and the evidence to inspect.