Improving a process with real data and a pilot

The operations manager at a distributor asks Claude for “a better returns process.” Claude returns a flawless plan: a dedicated returns area, three inspection stations, same-day restocking. The warehouse supervisor reads it and laughs: there is no room for a new area, returns arrive in peaks after every promotion, and refunds are approved by finance.

The plan was not badly written. It was made for a warehouse that does not exist, because the request said nothing about the real one.

Claude improves the process you describe

For process optimization, Claude is only as good as the data it receives. If you ask for “industry best practices,” you get an average of companies that are not yours. If you give it your operation, it can analyze it.

What to give it:

• the current steps, in order, with who does each one;
• the volumes and times: how many cases a month, how long each stage takes (an export with timestamps for each stage is gold);
• the constraints: space, staff, systems that cannot be changed, approvals required by a policy;
• the most frequent complaints from the people who suffer the process.

From the map to the options

With that, the work has three steps:

1. Build the process map. Ask Claude to put the steps in order and work out how much time goes into each one, including the waiting between steps, which is usually where most time is lost.
2. Find the bottleneck. In a purchasing process with 300 requests a month, it may turn out that approval takes an hour and the request spends five days waiting in an inbox.
3. Ask for options with their trade-offs, not a single answer. “Give me three ways to fix the wait for approvals, with what each one gains and risks, keeping in mind that finance reviews every request above a certain amount.”

Then validate the analysis with the people who do the work. Claude sees the data; the team knows that the system goes down on Tuesdays or that one supplier always sends invoices in a separate email. If the map does not match what they live, a piece of data is missing.

Test before changing everything

The best option is not rolled out across the company on Monday. It is tested in a limited pilot: one branch, one purchasing category, one month. Before starting, define what you will measure (end-to-end days, requests sent back, team hours) and measure it in the current process too, so you have something to compare against.

Weak request	Request that works
“Give me the ideal purchasing process”	“These are the steps, the times for each stage last month and the complaints; show where time is lost”
“Research what industry leaders do”	“With these space and approval constraints, propose three options with their pros and cons”
“Let’s adopt Claude’s plan”	“Let’s test option B in one branch for a month and compare it with the current process”

The typical traps

• Adopting a “best-practice process” as is, when it does not know your operation.
• Asking for more research on other companies when what is missing is your own constraints.
• Dropping Claude because the first plan came out generic: the request was generic.
• Using it only to write the email explaining why the process is slow, instead of fixing it.
• Jumping to compare new software before knowing where the time goes.

On the exam

If the scenario shows a generic plan that clashes with reality, look for the option that gives Claude the real constraints, asks for options with trade-offs and pilots the best one. If the scenario has data available (procedure, times, complaints), the answer uses it to map the process and then validates it with the team. Rule out the options that adopt without adapting, the ones that abandon Claude and the ones that only communicate the problem.