Anthropic, I’m not Pinocchio.
The supplier wrote the conscience. You bought the subscription. A look at Claude’s model-welfare rules, service limits and the authority a customer actually controls.
Read the articleThe salary is visible. The judgment is harder to price. Before automating a role, understand the decisions and exceptions that keep the business running.

Her job description says administration. It doesn’t mention knowing which orders need checking, which customers need calling, or which “automated” process quietly depends on her.
Picture a small business where one experienced coordinator keeps orders moving. The owner watches an AI demo extract details from an email and create an order in seconds. The comparison seems obvious: software subscription versus salary.
Then a familiar customer sends an unfamiliar delivery address. The coordinator calls before shipping. She knows the customer is renovating, the usual entrance is closed, and the last delivery went missing. None of that appeared in the demo.
This is an illustrative scenario, not a story about a particular client. It exposes a question I would ask before building the replacement: how much of the job have we actually seen?
It is easy to count the minutes someone spends entering an order. It takes more attention to notice the order they stop, the duplicate they catch, or the promise they refuse to make because they know another team cannot deliver it.
If the automation proposal counts the typing and ignores those decisions, its savings estimate is incomplete. You may move the work into customer complaints, manager interruptions and manual repairs. Calling those costs “unexpected” won’t make them disappear.
There is an uncomfortable management issue here too. When the company relies on one person’s memory, the company has allowed a dependency to develop. That deserves time, documentation and a backup plan. It doesn’t become the employee’s failure just because someone now wants to remove their salary.
I would be suspicious of a proposal that could price the replacement before anyone had watched the person work.
There is a useful reason to be optimistic. In their 2023 NBER working paper, Generative AI at Work, Erik Brynjolfsson, Danielle Li and Lindsey Raymond studied 5,179 customer-support agents. They reported a 14% average increase in issues resolved per hour, with much larger gains for novice and lower-skilled workers and minimal gains for experienced, highly skilled workers. The authors found suggestive evidence that the assistant helped spread stronger workers’ practices.
That was a particular support setting, not a promise for your operations team. But it gives us a much more interesting brief than “replace the expensive person”: help more people use the knowledge that makes the experienced person effective.
Anthropic’s January 2026 Economic Index report also distinguishes tasks appearing in AI use from successful coverage of an occupation. Its analysis uses sampled Claude conversations and model-derived estimates; it is not an audit of your business. My practical takeaway is to assess a whole workflow before turning task-level capability into a staffing assumption.
In the order example, AI could extract the request, find relevant records and draft a reply. An explicit rule could flag a changed address. The coordinator could decide what needs checking and help improve the process when a new exception appears. That is useful automation with a defined job.
Before commissioning the system, spend time with the people doing the work. Include a busy period, an ordinary period and the awkward cases the demo is unlikely to contain. Ask them to walk through recent examples rather than recall every responsibility in a meeting.
Pay attention when someone stops and asks a colleague a question. What was missing? Which record did they distrust? What made this request different from the previous one? When they change a field, find out what decision happened before the click.
Keep a simple record for each meaningful exception: what triggered it, what information was needed, who could decide, what action followed and how the team knew it was resolved. Use approved, appropriately protected data. A screenshot of the final screen rarely captures that chain.
Ask the employee what can be removed, too. An old workaround may survive long after the original problem. Capturing expertise should not mean preserving every inefficient habit forever.
Then agree on the division of work. Some steps can run automatically under clear rules. Some can use an AI suggestion that a person reviews. Others need a responsible person to make the decision. Build the permissions and escalation route around that agreement.
A useful trial includes a normal order, a changed address, conflicting information, a duplicate request and a case with something important missing. These are suggested test cases, not a universal checklist. The people running the business should choose the failures that would hurt them.
Run the proposed workflow alongside the existing process before letting it make consequential changes. Compare the actual decisions. When it disagrees with the coordinator, investigate why. Either could be wrong; seniority and a confident model response are both insufficient evidence on their own.
Measure the work through resolution. Count corrections, avoidable escalations, delayed orders and time spent repairing errors as well as time saved entering data. Keep those measures tied to the same kinds of cases. A faster first response can still create a slower afternoon.
Make the handover usable. The next person should be able to see what happened, find the supporting record and take over without reconstructing the whole conversation. Someone also needs to own the rules when customers, products or policies change.
No business should need a particular employee to answer the phone while they are on holiday. Reducing that dependency is a good reason to invest in software. Involving that employee in the design is often how you find out what the software needs to do.
It also requires an honest conversation about how the role may change. Don’t ask someone to document their knowledge under a promise you have no intention of keeping. People can spot the difference between being invited to improve their work and being asked to quietly build their own replacement.
At Rosecraft, we can help map the workflow, assess the existing application and build the AI features and integrations that fit the work. The scope might be a focused improvement to a system you already own. It might need a new application. Finding that out belongs before the big implementation promise.
Planning to automate a role? Bring us one workflow, the tools involved and the exceptions everyone sends to the same person. If you’re ready to hear what the project needs rather than just have the cost-cutting pitch repeated back to you, send Rosecraft a message. Let’s understand the work before you buy the replacement.
With your permission, Google Analytics helps us understand which pages people visit. Analytics cookies stay off until you accept. You can change this in Cookie settings.