Field guide

Replace manual intake without another unused tool

A request comes in by email, phone, a form or a text. Someone reads it, decides what it is, and re-types it into a spreadsheet, then the CRM, then a message to a coworker. This guide is about replacing that with something that holds up.

Free · about 9 minutes · no signup

Panel A shows email, phone, form and text arrows converging on one person who re-types into a spreadsheet, a CRM and Slack, with one path dropping silently. Panel B shows the same four channels feeding one routed pipeline with explicit stop and alert branches. A · TODAY, THE HUMAN API EMAIL PHONE FORM TEXT ONE PERSON reads, decides, re-types SPREADSHEET CRM SLACK DROPPED, NO ALERT ONE HOUR A DAY, RE-TYPING B · REBUILT, ONE PIPELINE EMAIL PHONE FORM TEXT ROUTE BY SHAPEone path per input type AI AT THE JOINTSto a forced schema DETERMINISTIC WRITEboring, testable, correct SYSTEM OF RECORDunchanged, still yours NOT SURE?it stops and asks FAILS?it alerts loudly
The same four ways in, built two ways. In A, a person is the connection between systems. In B, the path is, and the exceptions have somewhere to go.

01When a person is the connection between systems

“honestly right now i feel like a glorified data entry clerk.”Logistics coordinator, posted on Reddit

That is not a staffing problem. Your systems do not talk to each other, so a person became the connection. That setup fails in three ways.

F1

It does not scale.

Every new customer adds more re-typing. Past a certain volume, requests wait in a pile while the person doing the typing falls behind.

F2

It runs on memory.

The rules for who gets what, and how each customer likes things done, live in one person’s head. When that person is out, the work stops. The get it out of their heads guide covers this one.

F3

It fails without a sound.

Nothing announces that a request fell on the floor. A work order sits open for weeks because it got buried. The first alert is an angry customer.

02Why your last automation attempt died

You may have tried to fix this already with point-and-click automation, a shared base, or an agency build. One business owner posted about running on that kind of setup for six years.

“No alert. No error. Three weeks later a customer called asking where her order was.”Business owner, posted on Reddit
The same dropped handoff between two bases, drawn twice. In the silent version no alert edge exists and the customer calls three weeks later. In the loud version an alert fires at the break and the problem is fixed before she calls. A · FAILS SILENTLY BASE A DROPPED BASE B NO ALERT, NO ERROR CUSTOMER calls 3 weeks later B · FAILS LOUDLY BASE A SAME DROP BASE B ALERT FIRES AT THE BREAK YOU FIX IT before she calls
Same bug, two setups. The only difference is whether an alert fires at the break.

Another poster named the second way these projects die.

“If the answer is ‘call the consultant,’ the automation is dead.”Posted on Reddit, r/automation
The bar to clear
  • When it breaks, does it break loudly?
  • When it is not sure, does it stop and ask, or does it guess?
  • When something changes, can your own team adjust it?
  • Is there a number that proves it worked this month?

Want to see where you stand first? Take the two-minute silent failure audit.

03Five rules for intake automation that holds up

A plan view of an intake pipeline in six segments: inbound, route, extract, verify, write, record. Only the extract segment is hatched as AI. Callout leader lines drop from the segments to the five rules. PLAN VIEW · WHERE AI EARNS ITS PLACE HATCHED = AI 1 2 3 4 5 6 INBOUND ROUTE EXTRACT VERIFY WRITE RECORD R3 · ROUTE BY SHAPE R1 · AI ONLY AT THE JOINTS R2 · NO SILENT GUESSES R4 · APPROVAL ON CREATES R5 · THE RECORD STAYS YOURS SOLID = PLAIN SOFTWARE. TESTABLE, BORING, CORRECT.
The five rules are positions in one system. One step uses AI. The other five stay plain software on purpose.
R1

Plain software first, AI only where it earns its place.

Most of intake is not an AI problem. Moving a record, checking a status, matching an ID and sending an alert are plain software, which is easy to test. AI belongs where judgment lives: reading a messy request, sorting a document, pulling fields out of free text.

R2

No silent guesses.

If a customer writes “47 inches,” the system keeps 47, even if your catalog only has 48. It flags the difference and asks. When the AI step is unavailable, the request shows as waiting, never as a guess.

R3

One path per kind of request, and partial means partial.

A forwarded email, a phone message and a scanned form are different shapes. Each one gets its own way of pulling out the details. If a step times out halfway, the request is marked partial, not done.

R4

Approval before the system creates new records.

Let the system fill in records freely, but ask a person before it creates a new customer or company. That one check keeps duplicates and junk out of your CRM.

R5

Your system of record stays your system of record.

Build on top of the tools that already work. Ripping them out and migrating is how automation projects stall.

04Map your own intake on one page

Pick one intake, not “automate the office.” Write the real process, one step per line, including every re-type and every “ask someone” step. The map builds itself and you can copy it.

Tool · the one-page intake map

Include every re-type, every handoff, and every step where someone has to ask what to do.

Where do requests arrive?

Failure behaviors you have already decided

Leave an option unselected if it is still undecided.

Want a score instead of a map? The intake bottleneck scorecard grades one intake in two minutes.

Want your intake built this way?

Send me your map. I will tell you where AI belongs in it, where plain software is enough, and what it takes to build on the tools you already have.