Skip to main content
TekStudio.ai

Topic

Using AI in Your Business

Which work to hand over, which to keep, and how to get from a good result to a process that runs.

Reviewed yearly 12 min read9 articles in this topic

Questions this answers

  • What should I automate first?
  • What will AI never do well enough to hand over?
  • Why did our pilot never turn into anything?
  • Should I automate this or hire someone?
  • How do I get my team to actually use it?

Most AI projects in small businesses fail in the same unremarkable way. Somebody tries a tool, gets a genuinely impressive result, shows a colleague, and then nothing happens — because a good result is not a process, and nobody made it into one. The gap between "this worked once" and "this runs every week without me" is where almost all the value is, and it is almost never a technology problem.

What makes a process worth automating

The pattern is consistent enough to be predictive, which is unusual and useful. Before evaluating any tool, evaluate the work.

Good candidates

  • High volume, low variation — the same shape of task repeatedly
  • Clear inputs and an output somebody can check
  • Text-heavy: reading, drafting, summarising, extracting, classifying
  • Already documented, or easy to describe out loud
  • A bottleneck, where the delay costs more than the labour

Poor candidates

  • Low volume — a few times a month will never repay the setup
  • Every instance different, rules living in one person's head
  • Being wrong is expensive, unrecoverable, or regulated
  • The process is broken, and speed would only spread the mess
  • Nobody will own it after launch
The bottleneck exceptionOne case beats every calculation. If quotes take three days and you lose work to whoever answers first, the value of automating that step is the jobs you win, not the hours you save — and that number is usually far larger than any labour saving. Hours-based arithmetic badly understates bottlenecks, so treat one as a yes even when the maths looks lukewarm.

What stays human, and why it is structural

Some limits are temporary and will close as models improve. Others are structural and will not, because they are not capability questions at all. Knowing which is which stops you waiting for a release that was never going to help.

The durable ones:

  • Accountability — someone has to answer for the outcome, and that is assigned to a person or a company, never to software
  • Judgment the business is liable for — pricing risk, hiring, anything you would sign
  • Relationships, where the point is that a person paid attention
  • Physical and sensory work, where the information was never text
  • Genuinely first-of-its-kind decisions, with no precedent to pattern-match against

Everything else is negotiable, and the realistic ceiling even on a good candidate is that AI does the first pass and a person checks, corrects, and owns the result. That is genuinely valuable — a good first draft removes most of the effort — and it is not the whole hour. Any plan that assumes otherwise will disappoint in month two.

Why the pilot never became a process

This is the single most common failure, and it has a specific shape. Someone gets an excellent result by typing a long, thoughtful, one-off instruction into a chat window. The result is real. But the instruction lived in that person's head and that conversation, so nobody else can reproduce it, and neither can they next Tuesday.

What turns a result into something that runs:

  1. Write the instruction down as a reusable template

    The exact wording that worked, with the variable parts marked. This is the artefact. A result you cannot reproduce is a demo, not a process.

  2. Include an example of good output

    Showing the model your best previous version of the same document changes the result more than any other single adjustment — more than model choice, more than clever phrasing.

  3. Decide who checks it and against what

    Name the person and the standard. "Someone will notice" is not a control, and unowned quality drifts within weeks.

  4. Run it ten times before you judge it

    One good result tells you nothing about reliability. The tenth run tells you whether this survives contact with the ordinary variation in your work.

Getting a team to actually use it

Adoption fails for social reasons far more often than technical ones. In most teams a couple of people are enthusiastic, several are quietly sceptical, and the majority are unsure whether they are allowed to and are not going to ask.

What consistently helps:

  • State plainly what is allowed, so nobody has to guess — a one-page policy does more for adoption than any training session
  • Work real tasks in the room rather than demonstrating a generic example; the moment it clicks is when it is their own work
  • Have the sceptics try to break it, and take what they find seriously — they usually find the genuine limits fastest
  • Do not measure adoption by usage figures; measure it by whether one process actually changed
  • Provide the approved tools before you prohibit the unapproved ones

Automate or hire?

The comparison is usually a false one. For a narrow, repetitive, well-defined task, AI is dramatically cheaper than a person and always will be. For anything involving judgment, relationships, or accountability, you are not choosing between two ways to do the same job — only one of the options can actually do it.

The framing that holds up: AI changes what one person can cover, which usually means hiring later rather than not hiring. And if a role would be half spent on routine drafting and data shuffling, automating those first tells you what the job actually needs to be — which sometimes changes who you should hire.

What should a small business automate with AI first?

The highest-volume, lowest-variation process where being wrong is recoverable — which for most service businesses is follow-up and first-draft written material. Resist starting with your most expensive process: it is usually expensive because it needs judgment, which is the hardest kind to automate and the worst place to learn.

Why do most AI pilots never turn into anything?

Because a good result is not a process. The instruction that produced it lived in one person's head and one conversation, so nobody could reproduce it — including them, a week later. Writing the prompt down as a reusable template with an example of good output is the step that converts a demo into something that runs.

How long does it take to see results from AI?

For a well-chosen first project, days to see whether it works and a few weeks to have it running reliably. If a proposal quotes months before anything is visible, either the project is too ambitious for a first attempt or the process underneath needs fixing before automation is the right conversation.

Do I need a developer to use AI in my business?

For the common cases — drafting, summarising, configuring an existing tool properly — no. You need help when the requirement crosses systems: AI that reads your CRM, updates your job management software, and emails the client. That is integration work with real failure modes, and it is where doing it yourself tends to stall.

How do I get staff who are sceptical about AI on board?

Take the scepticism seriously rather than trying to overcome it — the sceptics usually find the genuine limits fastest, and that information is valuable. Work their real tasks in front of them, be explicit that a person still owns the output, and let them break it. Enthusiasm imposed from above tends to produce compliance rather than use.

If you do one thing

  • Pick a high-volume, low-variation process where being wrong is recoverable. Not your most expensive one.
  • Expect AI to do the first pass and a person to check and own the result. Plan for that, not for full automation.
  • Write the working instruction down as a template with an example. That is what turns a result into a process.
  • Treat a bottleneck as a yes even when the hours-based maths is lukewarm.
  • State what is allowed before you worry about adoption — most people are unsure, not resistant.

Everything we have written on this

The structured version

Same ground as a free course — objectives, sequence, and a record of what you have finished.

  • Choosing Your First AI Project Most first AI projects fail because they were chosen to be impressive rather than to be finishable. A scoring method, a success test, and the traps to avoid.
  • Writing Instructions That Work The difference between a useless answer and a usable one is rarely a clever trick. It is context, audience, format, and constraints — stated out loud.
  • Turning One Good Result Into a Process Everyone gets a great result once. Almost nobody turns it into something the team uses on Tuesday. Here is what closes that gap.
  • Rolling AI Out to Your Team Why rollouts stall two weeks after launch, and a three-phase approach that produces lasting adoption instead of a brief spike.
  • Measuring Whether It Actually Worked Without measurement, AI adoption drifts one of two ways: abandoned because nobody can show it works, or kept with nobody accountable for whether it does.

Tools for this

Related topics

What AI Costs a BusinessBudget for AI without being surprised by the bill or oversold on the savings.Trust, Safety, and Your DataKnow what is genuinely risky about AI and what is just noise.