Help with a task is not the same as finishing the work.
An AI tool can summarize an email, extract a field, draft a reply or recommend an action. People may still gather the rest of the facts, apply the rules, resolve the exception, update the records and check that the case is actually done. These are illustrations.
Sales follow-up
AI drafts a sales follow-up. An employee still retrieves the latest CRM information, corrects the draft and updates the record.
Invoice handling
AI extracts invoice details. Employees still investigate mismatches, retrieve missing data and complete the ERP workflow.
Project status
AI summarizes project status. Managers still consolidate updates from different systems and chase missing information.
Why a workflow stops short of completion.
Partial automation usually has a specific cause. GreyShacks looks for that cause in the workflow you already run.
The information is not ready
Facts are missing, unreliable, or spread across applications, so a person still assembles the case.
The systems cannot carry the action
An application does not expose the step the workflow needs, or the systems do not stay in step with each other.
The rules are not explicit
Business rules and exception paths live with experienced people. The system has nothing dependable to apply.
Completion is hard to verify
An agent can take a step and still be unable to confirm that the business outcome actually happened.
Authority is unresolved
Permissions, approvals and risk boundaries are unclear, so consequential actions wait for a person by default.
The tests are thinner than the work
Happy-path demos pass. The variations, failures and handoffs of the live process were never tested.
Start with an Autonomy Assessment.
The assessment is for a company that already uses AI, agents or automation software, and still relies on people to supervise, correct or finish a meaningful part of one workflow. It is a scoped engagement. It does not guarantee full autonomy, and it does not include implementation unless you commission that next.
What you bring
- One workflow with a recognizable trigger, volume and outcome.
- The applications and records it already uses.
- Where people still gather information, decide, or finish the case.
- An owner who can explain the rules, the exceptions and the approvals.
What we investigate
- Data sources and whether they are complete enough to act.
- Applications, APIs and the actions they do and do not expose.
- Business rules, decision points and exception paths.
- Permissions, failure modes and how completion is verified.
Five questions the assessment answers
- 01What does the process involve, from the trigger to the business outcome?
- 02Which steps already run without a person, and where does someone still intervene?
- 03Why is that intervention still required?
- 04What can safely run autonomously, what needs approval, and what is not ready?
- 05Which technical, operational and governance changes would reach the next meaningful level?
What you receive
The written assessment distinguishes facts supported by your evidence, assumptions that still need validation, and scenarios that still need testing. Implementation, if you want it, is a separate decision based on those findings.
Current-workflow map
The process from its trigger to the business outcome, including the systems it already touches.
Intervention and blocker analysis
Where people still step in, and the data, system, rule or permission issue behind each intervention.
Exception and failure register
The cases that break, the failure modes, and which of them are evidenced, assumed, or still untested.
Autonomy readiness
What can run on its own, what requires approval, and what should stay with a person for now.
Remediation plan
The changes in priority order. An assessment can recommend waiting.
Implementation blueprint
Integrations, permissions, tests and monitoring the next level would require.
Business case
Stated assumptions, and the metrics to measure after implementation. The baseline is taken for this workflow.
Illustrative walkthrough, drawn from an anonymized manufacturing case. Not a measured result.
Follow-up still waits on someone to assemble the case.
In an anonymized manufacturing engagement, sales follow-up and shipment exceptions depended on people moving between CRM, email, messaging and ERP. The published account describes the operating problem and the controls that were designed. It does not report completion rates, time saved or cost.
How the work started
- A customer asked about a late shipment or a stalled opportunity.
- Sales, operations and finance each held a different piece of the status.
- Supplier holds lived in email. Receipts lived in ERP. Payment status lived in a spreadsheet.
- Someone reconstructed the story before the company could answer.
Where people still carried it
- A copilot could summarize an email thread. It could not see a warehouse hold or a payment status.
- Follow-up quality depended on whoever was available.
- The next shift inherited fragments, and rebuilt the case.
What that engagement changed
- The exception workflow was specified first: what should be known, who may see it, and what the system may do.
- Context from email, ERP signals and commercial trackers was connected under the permissions that already existed.
- An agent drafted customer updates and internal follow-ups. Nothing customer-facing was sent without confirmation.
Controls on the workflow
- Source-system permissions stayed in place. Finance fields stayed with finance roles.
- The agent had its own identity and a narrow set of actions.
- Retrieval, drafts and confirmations were written to an audit trail.
- A person confirmed any message that could change what the customer had been promised.
Success is a completed case.
The baseline and the target are set for each workflow before implementation. GreyShacks does not publish a promised percentage.
- Percentage of eligible cases completed end to end.
- Percentage of cases that still need a person.
- Human time per case.
- Processing time.
- Error and rework rates.
- Exception and escalation rates.
- Cost per completed case.
- Compliance with the agreed operating rules.
Why companies bring the workflow here.
Many companies already run UiPath, Microsoft Power Automate, ServiceNow, other automation tools, internal engineering, or an outside consultant. GreyShacks works on why that setup still cannot finish the workflow reliably, and on the changes required to close the gap. We do not claim to replace those tools.
The process comes first
The engagement starts from the workflow and the outcome it is supposed to reach. The tools follow the blockers.
Use the systems you already run
Where it is practical, the work connects to the CRM, ERP, case tools and records already in the process, including automation software you have already bought.
Name the root cause
A missing record, a closed API, an unwritten rule and an unresolved approval are different problems. Adding a model to every step is not the default recommendation.
Leave the right work with people
The assessment separates a genuine autonomy blocker from a decision that should stay with a person because of risk, law, ambiguity or judgment.
The diagnosis can be built
The assessment names the engineering, permissions and tests. You can commission that work, or stop after the written diagnosis.
Success is the completed case
The measures are workflow completion, human intervention, errors, time, cost and reliability. A count of automated clicks is not the result.
What the published cases support.
Client names stay private. Each page describes an anonymized operating problem, the work that was done, and the controls. They do not report measured completion rates, cost or time savings, and they are not a forecast for the next workflow.
Manufacturing
A sales team was losing qualified opportunities because follow-up depended on manual coordination across CRM, email and messaging systems.
Professional services
Delivery leaders could not see which engagements were at risk because status lived in email, slides and the memories of project managers.
Diversified operations
A diversified family enterprise had AI experiments in three businesses and no common way to decide what should be allowed to act.