We sell automation. Chatbot flows, support rules, sales sequences, AI agents — automating work is literally the product. Which is exactly why we keep a list of things we think you should not automate, and why the product is full of mechanisms — approval queues, hard caps, handoff paths, category locks — for keeping humans in charge of them.
This is that list, with the reasoning. It is the advice we would give a friend setting up their operation, including the parts that sell fewer credits.
The three tests
Before the list, the framework. A task is a good automation candidate when it passes all three:
Frequency. It happens often enough that the setup cost pays back. Automating a twice-a-year task is a hobby.
Reversibility. A mistake can be undone in one step. Tagging a record: reversible. Sending an email: not — you can send a correction, but you cannot unsend. Reversibility is the test people skip, and it is the one that decides how bad your worst day gets.
Describability. You can write the rule down completely — including the edge cases — and the rule stays true next month. If your best description ends in “…unless it feels off,” the feeling is doing unautomatable work.
Frequent, reversible, describable: automate freely. Everything else deserves a closer look — and the failures cluster in recognizable families.
What should stay human
1. The angry customer
Automation handles the transaction of an upset customer fine — routing the ticket, pulling the order history. It cannot handle the relationship moment, because what an angry customer needs first is evidence that a person noticed. A perfectly-worded automated response to fury reads as an insult precisely because it is perfectly worded. Nothing says “we don’t care” like obviously nobody having read it.
Route by all means — in fact, automate the detection: rules that catch sentiment and keywords and set priority so an angry ticket never waits behind a feature request. Then put a human on the reply. In Oneop terms: support automation sets the priority; a person writes the answer, with an AI draft to edit if it helps — the AI-draft button hands the agent something to review, it never auto-sends.
2. Judgment calls about money
Refund exceptions, goodwill credits, discount requests, “can we waive this fee” — decisions that are cheap individually and precedent-setting in aggregate. They fail the describability test (the policy always has an “…it depends”), and half of them fail reversibility.
This is why Oneop’s AI agents refuse finance and stock actions by default regardless of the autonomy level set on the agent — the category sits behind a separate opt-in switch, so touching money requires two deliberate decisions by different mechanisms. We wrote up the full model in Autonomy levels: suggest, approve, autonomous. The books themselves are the same story from the other side: posting, balancing and period locks should be deterministic mechanisms, not AI — see Double-entry accounting, explained for founders.
3. Exceptions — by definition
Automation is codified precedent; an exception is precisely the case with no precedent. The order that is both damaged and past the return window and from your biggest account. No rule you wrote covers it, because if it were coverable, it would not be an exception.
The design principle: automations should detect and surrender, not stretch. A rule that cannot classify confidently should escalate to a person, visibly — which is why Oneop’s agent runs end as escalated with the exit reason recorded when they hit a ceiling, rather than improvising a conclusion, and why the chatbot’s honest “no agent available” path exists instead of a bot that fakes competence at 2 a.m. An automation that knows when to stop is worth ten that do not.
4. Apologies and bad news
When you got it wrong — a missed shipment, a billing error, an outage — the apology is not information transfer; it is accountability transfer. Its entire value is that a person put their name on it. Automate the detection of who deserves one, draft the facts if you like, and then have a human write and send it. Same logic for delivering bad news: a price increase, a discontinued product, a “no” to a long-standing request.
5. The first weeks of anything new
A new product line, a new market, a new support topic: you cannot automate what you do not yet understand, and early automation freezes your ignorance into rules. Do the work manually until the patterns bore you — boredom is the signal that the rule is now describable. Then automate it. Your ticket history from the manual weeks becomes the KB and flow spec, as covered in grounding a chatbot.
6. Anything you would need to defend later
Contract terms, compliance judgments, hiring decisions, public statements. The test here is simple: if this went wrong, would “the system did it” be an acceptable sentence in the explanation? If not, a person decides — with as much machine-prepared context as you can give them.
The middle ground is where the value is
The list above is not an argument for manual work. Almost every “keep it human” item has an enormous preparation component that machines do better: gathering the history, drafting the text, extracting the document, proposing the action. The pattern that captures both halves is AI prepares, human decides:
- Drafted replies the agent edits and sends — never auto-sent.
- Agent actions queued for approval, with the full reasoning trace attached, worked as a queue twice a day instead of six interruptions.
- OCR-extracted bills and receipts a human confirms before anything posts.
- Suggested priorities and routings that a rule applies but a person can override.
You get most of the time savings, and the judgment, tone and accountability stay attached to a name. Most of Oneop’s AI surface area is deliberately built in this shape — which is also why every run keeps its trace: reviewability is what makes delegation to software safe enough to expand.
Revisit the line, on evidence
The boundary is not fixed. Tasks migrate across it as they become boring and well-understood — and occasionally migrate back after an incident. The healthy cadence is quarterly: look at what humans spent time on (your ticket and task history has the answer), find what newly passes the three tests, and promote it — through suggest, then approve, then autonomy, never straight to the end.
Automate the repetitive so your people can be human at the moments that need one. That is the pitch, honestly stated — and if you want tooling built around that boundary rather than against it, the free plan gives you two seats with no credit card, and every automation in the product ships with a human-shaped escape hatch.