skip to content

writing / 2026-07-10 · 2 min

The first internal AI tool your company should build

Every week a company asks some version of: "We should be using AI internally — where do we start?" Almost every week the wrong answer wins: a chatbot over the company wiki.

Here's the selection rule I use with clients instead.

Look for the drafting bottleneck

Somewhere in your operation, a competent person spends hours producing first drafts of something formulaic: replies to reviews, outreach messages, quotes, appointment confirmations, status summaries, ticket triage notes. The pattern to hunt for:

  • the input already exists digitally (a call, a form, a review, a record),
  • the output follows a shape a senior person could describe in a page,
  • a wrong output is embarrassing but recoverable, and
  • a human already reviews it anyway — or easily could.

That last point is the whole trick. Draft-plus-approval is the highest-ROI, lowest-risk architecture in applied AI right now. The model does the tedious 80%; a human spends seconds on the judgment 20%. You get the speed without betting the brand on a model's worst day.

Why not the chatbot?

Because a chatbot's value depends on retrieval quality, answer trust, and adoption habits you don't control. A drafting tool slots into a workflow that already exists — the drafts appear where the person already works, they approve or edit, done. Adoption is not a project; it's Tuesday.

I've shipped this shape repeatedly: an AI receptionist that drafts bookings and follow-ups for a home-services business, a review-reply system that drafts responses at app-store scale, an outreach engine that drafts first-touch messages but is structurally incapable of sending them itself. Different industries, same architecture, same goal: give the hours spent drafting back to the person doing the judging.

Scoping it: the one-page spec

You need four decisions, and they fit on a page:

  1. Trigger — what event produces a draft? (new call transcript, new review, new lead)
  2. Grounding — what may the model read? (your docs, the record, past examples — retrieval, not vibes)
  3. Guardrails — what must it never do? (send, delete, promise refunds, quote prices)
  4. Approval — who accepts, where, and how fast? (a queue in Slack or a phone-friendly review screen beats a new dashboard)

If a vendor or engineer can't answer all four crisply, the project isn't scoped yet.

What it costs to get wrong

The failure mode isn't the model writing something silly — approval catches that. The failure mode is plumbing: duplicated sends when a job retries, drafts grounded on stale data, no audit trail when someone asks "why did we say this?" That's engineering, not prompting, and it's where most internal AI tools quietly die.

Build the boring parts well — idempotent jobs, real queues, an audit log — and the AI part becomes the easy layer on top.

If you want help finding and shipping your first one, this is what I do.