← All posts
· Tangle Web Services · 5 min read

Where to start with AI when everyone is selling you everything

Getting startedStrategy
Isometric illustration of a winding path through options resolving into one clear orange route with a starting flag

Most of the small business owners who call us have already watched a dozen AI demos. They've seen the chatbot that writes poetry, the tool that turns a sentence into a video, the assistant that books meetings. They're impressed and a little anxious, and the question they ask is almost always the same: "So what should we actually do with this?"

It's the right question. And the honest answer is that the flashy demos are usually the worst place to start.

Start with the work you already hate

Here's the rule we give people: don't look for where AI is exciting. Look for where your team is bored, slow, or making mistakes. The first project should attack a task that is repetitive, happens often, and has a clear right answer most of the time.

A few that come up again and again:

  • Copying information from emails or PDFs into a spreadsheet or your CRM
  • Answering the same fifteen customer questions over and over
  • Sorting incoming requests so they get to the right person
  • Drafting first versions of quotes, replies, or reports that a human then edits

None of these will impress anyone at a dinner party. All of them quietly eat hours every week. That's exactly why they're good candidates. The work is predictable enough that a machine can do most of it, and valuable enough that getting an hour back per person per day actually shows up in your week.

The test we use: frequency times pain

When a client can't decide between three ideas, we score each one on two things.

First, how often does it happen? A task that runs 200 times a week is worth far more attention than one that runs twice a month, even if the twice-a-month task feels more annoying in the moment.

Second, how much does each instance cost in time, errors, or delay? A five-minute task done 200 times a week is roughly 16 hours. That's two days of someone's life, every week, gone to copy-paste.

Multiply the two. The highest number usually wins. It's crude, but it drags the conversation away from "what's coolest" and toward "what's actually bleeding."

Why your first project should be small on purpose

There's a temptation, once you've decided to do this, to go big. Automate the whole sales pipeline. Build the assistant that knows everything.

Don't. Your first AI project is not really about the AI. It's about learning how your team reacts, where your data is messy, and whether the thing holds up when real customers hit it. You want to learn those lessons on something with a small blast radius.

We usually aim for a first project that:

  • Touches one team, not five
  • Can be turned off in an afternoon if it misbehaves
  • Has a human checking the output before anything goes to a customer
  • Shows a result you can measure within about a month

A project like that builds trust. And trust is the thing you'll need when you propose the bigger, scarier automation six months later.

The data problem nobody warns you about

Here's the part the demos skip. AI tools are only as good as the information you can feed them, and most small businesses keep that information in a mess. Customer history split across an inbox, a spreadsheet, and someone's memory. Product details that are right in one place and wrong in two others.

You don't need to fix all of it before you start. But you do need to be honest about it, because a chatbot trained on out-of-date prices will confidently quote out-of-date prices to your customers. We've seen it happen. The fix isn't more AI; it's picking a first project where the underlying data is already reasonably clean, then cleaning the rest as you go.

What "good enough" looks like

You're not aiming for perfection. You're aiming for a system that handles the routine cases well and hands the weird ones to a person. If an AI assistant can resolve 70% of incoming questions and route the other 30% to a human with a useful summary attached, that's a win. It means your team spends its time on the 30% that actually needs a brain.

Chasing the last 10% of accuracy is where budgets go to die. A tool that's right 95% of the time with a human reviewing edge cases will serve you better, and cost a fraction of what it takes to reach 99%.

A reasonable first ninety days

If I had to sketch the shape of a sensible start, it would look like this:

  1. Weeks 1-2: Pick one task using the frequency-times-pain test. Write down how long it takes today and how often errors happen. You need this baseline or you'll never know if it worked.
  2. Weeks 3-6: Build the smallest version that does the job, with a human in the loop reviewing output.
  3. Weeks 7-10: Run it for real on a slice of the work. Watch where it breaks. Fix those cases.
  4. Weeks 11-12: Compare against your baseline. Decide whether to expand, adjust, or scrap it.

That last option matters. Sometimes the answer is "this isn't worth it," and finding that out in twelve weeks for a small cost is itself a good outcome.

The honest caveat

AI won't fix a broken process. If a task is slow because nobody's sure who owns it, automating it just makes the confusion faster. We turn down projects fairly often because what the business actually needs is a clearer workflow, not a model. Sort the process first. Then automate the part that's genuinely repetitive.

If you're staring at a list of possibilities and can't tell which one is real, that's usually the moment to bring in someone who's done it before. We're happy to be that someone, but even a single honest conversation with a peer who's already shipped something will save you weeks.

The goal isn't to use AI. The goal is to get an afternoon back. Start there.