Pareto 8:2 — The Bot Strips Away 80% of Repetitive Execution
Count support inquiries by type and there are dozens of kinds, but the actual volume clusters in a few. Routine inquiries — account-identifier lookups, login and email changes, simple status checks — make up most of the incoming count. As a share of types they are only 20%, yet they eat 80% of the workload: a textbook Pareto 8:2.
This 20% of types have predetermined answers and are done after a single lookup of the operational DB. It is work people have no reason to repeat, and yet the very work that steals the most of their time. So it is the first target for automation. The AI CS bot strips away this 80% of repetitive execution.
How Does the CS Bot Handle Repetitive Inquiries?
We ran this structure in the support operation of a pharmacy-software company. When an agent calls the bot in an internal messenger channel, the bot queries the operational DB and replies with sources attached. Ask for a given pharmacy's account ID and it looks it up and tells you; send a request to change the signup email and it identifies the account, checks whether the change is possible, then guides through the steps or executes it directly.
Two things are key. First, sensitive changes go through human confirmation while simple lookups and guidance are finished automatically. Second, every answer cites the evidence it looked up, keeping hallucination in check. It is trustworthy not because the bot is clever, but because the data it references is accurate and its answers carry sources.
The Next Step — AI Plans and Builds New Services on Its Own
After stripping away repetitive execution comes planning and development. AI monitors posts in a domain community, analyzes them weekly, and produces a briefing on what the issues are and which unmet demands recur. It does not stop there: it auto-plans recurring demand into new services or features and files them as JIRA issues.
Then comes development. For an issue people have marked Go, AI builds it automatically and runs E2E tests. In other words, both the discovery and planning of 'what to build' and the implementation and verification of 'how to build it' move to the machine side. This is a structure currently being built at SH Consulting.
People Judge at Only Two Points — HITL
In this pipeline, people intervene at exactly two points. The first is the Go/Stop decision in the two-week sprint meeting: among the planning issues AI filed, people choose what to actually build. The second is functional testing after development: people give the E2E-passed output a final review and decide whether to ship.
The two points are not accidental. Setting direction (what to build) and owning release quality (whether to ship) are judgments people must make. The repetitive labor in between — monitoring, analysis, writing specs, coding, writing tests — is handed to the machine. This is the design principle of Human In The Loop (HITL).
Why HITL Rather Than Full Automation?
The danger of full automation is that it produces the wrong direction fast and at scale. Hand direction-setting and the ship decision to a machine, and the cost of undoing a mistake grows. The two human gates absorb exactly that risk. AI does not kill bad ideas on its own; people screen them with Go/Stop.
The more we hand to AI — from execution (the CS bot) to planning and building (the autonomous pipeline) — the more human work converges onto two judgment points. What AX points to is not pushing people out of the pipeline, but keeping people freed from repetition precisely where judgment is required.