The anti-slop playbook

The automation field guide most vendors will not hand you.

A blunt way to decide what to automate, what to buy, and what to leave alone. If your process fails the tests below, we would rather tell you now than bill you later.

Most AI pages sell motion. This one sells friction. The useful question is not “where can we add AI?” It is “where does a senior operator already know the rule, hate repeating it, and need the result checked before it reaches a customer?” That is where custom AI earns its keep.

DPR Labs is an elite senior AI studio, but the honest answer is often not “hire us.” Sometimes you should buy a mature tool. Sometimes you should wait six months. Sometimes the correct first build is not a model at all, but a metric, an owner, and a boring review queue.

Field rule

AI slop starts when nobody can name the number.

The market is full of teams confusing a demo with a business system. They show a chatbot, avoid the messy edge cases, and call the result transformation. Then the real work shows up: permissions, bad inputs, human overrides, audit trails, exception queues, and one angry manager asking why the “AI” made the job slower.

Our filter is harsher. A first automation candidate should be high-volume, rules-heavy, human-checkable, boring, and universally hated. If the work is glamorous, rare, political, or impossible to review, do not start there. Billion-dollar companies are built by deleting expensive repetition, not by putting a sparkle layer on unclear work.

Widget 01

AI-readiness scorecard.

Answer like an operator, not a deck writer. A “somewhat” means the weakness will show up in production. A “no” means you have scope work before you have automation work.

Score the workflow you are tempted to automate.

Data, metric, owner, guardrails.

DATA Does the process run on data that already lives in a system you can query?
DATA Is the input consistent enough that two people read the same record the same way?
DATA Can the data stay inside approved privacy, security, and contract boundaries?
METRIC Can you state the number that would prove the automation worked?
METRIC Do you measure that number today, so there is a before-and-after?
METRIC Would a 50 percent improvement be noticed by someone with a budget?
OWNER Is one named person accountable for this process and able to approve changes?
OWNER Will that owner still care about the result six months from now?
OWNER Can the owner hand you three recent real examples in the next hour?
GUARDRAILS If the system is wrong, is the damage recoverable instead of permanent or public?
GUARDRAILS Can a human review or reverse the output before it reaches a customer or ledger?
GUARDRAILS Are the rules stable enough that they will not be rewritten next week?
0/ 100

Widget 02

Build, buy, or wait.

Custom software is not a trophy. If a mature tool handles commodity plumbing, buy it. If the workflow changes every month, wait. Build when the work is central, frequent, measurable, and worth owning.

Choose the closest answer. The tree is intentionally opinionated.

Start here

Five workflows to automate first.

The shared signal is boring and powerful: high-volume, rules-heavy, human-checkable, boring, and universally hated. That combination beats almost every “AI strategy” workshop.

1. Inbound triage and routing.

Support tickets, leads, applications, and forms arrive constantly. The rules are visible, the output is easy to check, and the backlog annoys everyone.

2. Re-keying between systems.

If humans copy the same fields because two tools never got connected, automate the bridge before buying another dashboard.

3. Recurring report assembly.

Weekly ops, finance, and status roll-ups usually have the same shape. Let people review the story, not rebuild the spreadsheet.

4. Document and invoice extraction.

Pull fields into structure, keep a review step for totals and approvals, and measure the error rate before touching the ledger.

5. Reconciliation and exception flags.

Let automation find mismatches and queue the weird cases. Humans are better used judging exceptions than hunting for them.

The disqualifier.

If nobody owns the process, do not automate it. AI without an owner becomes another orphaned internal tool with a login nobody remembers.

The senior answer

Sometimes the right move is to walk away.

A workflow that scores “Not yet” is not a failed company. It is a warning label. Standardize the inputs, assign an owner, decide what a mistake may cost, and come back in a quarter. That is cheaper than paying experts to automate confusion.

Contrarian promise: if your best candidate does not clear the scorecard, we will say so. DPR Labs is built for serious automation, not AI theater.

Bring one ugly workflow

If the score is real, the pilot can be small.

Bring us the process you scored, the metric you would judge it by, and the person who owns it. If those three are real, so is the automation.

Book a pilot

See the DPR method