The most common failure mode for enterprise AI pilots is not bad technology — it is vagueness. Teams spend six weeks "exploring the potential" and end with a demo nobody can approve or reject. This plan compresses the evaluation into one week by forcing three decisions up front: one use case, one success metric, one decision-maker who will read the result. Everything else is execution.
Before Monday: pick one use case and define success
Choose a single, narrow task where the input and the desired output are both easy to describe. Good candidates: summarizing support tickets, extracting fields from invoices, drafting first-pass responses to a common email type. Bad candidates for week one: anything customer-facing, anything requiring integration with three internal systems, anything where nobody can say what a good output looks like.
Then write the success criterion as a sentence with a number in it. For example: "Claude's summary is usable without edits for at least 7 of 10 real tickets, as judged by the support lead." If you cannot write that sentence, you have not picked a use case yet — you have picked a theme.
Day 1–2: get access and make the first call
Use the cloud you already run — that is the whole point of the 3P platforms. Your existing account, billing relationship, and identity setup carry over, which means no new vendor onboarding for a one-week test. Depending on your cloud, follow the matching walkthrough: Bedrock, Vertex AI, Foundry, or Claude Platform on AWS.
Budget the full two days for this even though the code itself is short. The time goes to organizational plumbing: getting the model enabled in your account, getting a developer the right permissions, and getting sign-off to send sample data. For the test itself, start with Claude Sonnet 5 — it is the balanced workhorse tier and currently carries introductory pricing ($2 per million input tokens and $10 per million output tokens through August 31, 2026, versus $3 and $15 list).
Day 3: build the thin slice
Write the smallest script that takes a real input and produces a real output: a loop that reads ten documents from a folder, sends each to Claude with your draft prompt, and writes the results to a spreadsheet. No user interface, no queue, no database. The goal is to see your actual data meet the actual model.
Spend the afternoon iterating on the prompt, not the code. Most quality problems in week one are prompt problems: missing instructions, no examples, no stated output format. Two or three revision rounds against the same ten inputs typically move quality dramatically.
Day 4: evaluate against real examples
Now scale from ten inputs to a representative sample — fifty to a hundred real examples if you can get them, including the ugly ones: the scanned fax, the angry customer, the document in the wrong language. Have the designated human expert score each output against the success criterion you wrote before Monday. Record the score, but also record the kinds of failures. "Fails on handwritten forms" is an actionable finding; "sometimes it's off" is not.
Day 5: cost the workload and write the memo
From Day 4 you now know the average input and output size per task. Multiply by your real monthly volume and the per-token prices to get an honest monthly estimate — the method in Estimating Your Monthly Claude Bill walks through it. Then write a one-page memo for your decision-maker with four sections: the success criterion, the measured result, the estimated monthly cost, and the known failure modes. End with a recommendation: proceed to a production pilot, iterate another week, or stop.
A "stop" verdict is a successful proof of concept. You spent a week and a trivial amount of token spend to avoid a quarter of wasted effort. A "proceed" verdict comes with something better than enthusiasm: evidence.
Where to go next
If the memo says proceed, From Pilot to Production lays out the 90-day path, and the platform decision framework helps you confirm the surface you tested is the one you should commit to. The launch checklist covers what production readiness actually requires.