Calder & Lane
(APPLIED AI AUTOMATION)

Hours back from one dull job.

We do not sell an AI plan. We help you pick one repetitive job, bring in the engineers who can hand the dull part to software, keep a person on the judgment calls, and count the hours that come back.

(WHAT WE HEAR)

You are sick of hearing about it.

By lunch you have heard from another AI vendor. Every one of them says the same thing, and none of them asks how your business actually runs.

Somebody upstairs needs an AI answer for the board, and the pressure to turn into a tech expert by Friday feels real. So the question becomes how to fit AI into what you do, instead of what is slowing you down.

Meanwhile the AI pilot from last year is still a slide. The demo looked good, somebody said put it in production, and the last 20 percent turned into a tar pit.

You bought the licenses and most of them sit unused, so there is no return to argue about yet, only an adoption question. The tool that was supposed to save time made a new job: check it, correct it, rewrite it, manage what it produced.

Legal said no, partly because they are afraid and partly because nobody explained, in plain words, what the thing does with your data.

So AI stops looking like an opportunity and starts looking like one more thing on a to-do list that was already too long.

Almost none of that is a technology problem. Nobody sat down and said what the machine was for.

(HOW IT RUNS)

How one job gets its hours back.

Applied AI, as we use the words, is business process automation with a language model doing the reading and a person at the end of it. The whole method fits on one page, because a longer one would be the AI plan we said we do not sell.

We do not build any of it. The provider you choose does, and we are at the table for every technical conversation, asking the questions you would not know to ask.

  1. Pick one job. The dull one that eats the same afternoon every week: purchase orders, invoices into the accounting system, the inbox somebody sorts before anyone can start. We learn how your business runs before we name it.
  2. Count it first. Before anyone builds anything, what the job costs today goes on paper in numbers you already track, like hours, invoices posted, or days to a quote. You keep the record.
  3. Start with what you already own. Often the first job fits a setting or a connector in a tool you already pay for, not a new platform. Where it does not, we put more than one provider in front of you rather than the one that called you.
  4. Bring the engineers to the table. The providers' engineers explain what their tool will do with your data and what it will not, we ask the questions you would not think to, and you choose. The provider you choose builds it inside accounts you own.
  5. Put a person on the judgment calls. Software does the repetition and it will guess, so a named person on your side catches the guess before it counts and signs off on anything that needs a decision.
  6. Run it next to the old way, then count again. Keep the old way running beside the new one until the count is in, so nobody has to trust a demo. If the hours came back, the next job goes on the list. If they did not, it stops, and you keep everything that was written down.
(A FIRST AUTOMATION)

What a baseline automation actually looks like.

Not a strategy. Not a platform. One job, end to end, with a person at the point where judgment lives. Here is the most common first job, a supplier invoice, so you can see the whole shape of it.

  • The triggerA supplier invoice lands in the accounts inbox as a PDF, the way it does forty times a week today.
  • The readThe tool pulls the supplier, the invoice number, the amount, the date and the purchase order number off the page.
  • The matchIt checks those against the purchase order and the receiving record in the system you already use. Matched invoices move on.
  • The postMatched invoices are posted to the accounting system, coded the way your bookkeeper codes them today.
  • The exceptionAnything that does not match, a missing PO, a price that moved, a duplicate, goes to a named person with the reason written next to it. Nothing unmatched is ever posted on its own.
  • The numberHours per week on invoices before, hours per week after, counted in the same spreadsheet your bookkeeper already keeps. If the number does not move, it stops.
(THE NUMBERS)

Measured in your own numbers.

Without a baseline, every number about AI is an anecdote with a percentage sign on it. So the baseline comes first, before anyone builds anything.

We do not use the vendor's model, and we do not ask your team to guess what they saved. A spreadsheet about a company that does not exist, paid for by the vendor, is not evidence about your company, and self-reported savings are the weakest evidence there is.

We use the numbers you already look at on a Monday: hours on the task, invoices posted, quotes sent, tickets closed, days from order to invoice.

Then we count the new work too. Time spent checking and rewriting what the tool produced comes off the total, so the saving you see is net of the checking.

The count is a plain before and after, in your own units, in a record you keep. If the count says the job was too small to bother with, that is a result too, and you hear it before anything gets built.

(YOUR DATA, YOUR RULES)

Your data, your rules, your people.

Data worry rarely arrives as a privacy question. It arrives as legal saying no.

Or it arrives as the person who runs the books, who will not let software that guesses anywhere near the ledger. Or as a team that suspects the tool is there to replace them.

Every one of those is reasonable, and each one has an answer.

  • The worrylegal said no because they are afraid. What we do: the rules get written down before anything runs, in a short document you own. Which systems the tool can read, which it can write to, what it may never see, and where a person signs off. Legal reads one short document before anyone has to read a vendor's terms.
  • The worryour data ends up training somebody's model. What we do: we read the terms before you sign, and the provider's engineers show you, with us in the room, the setting and the tier that keep your data out of training. The tool runs inside accounts you own. If a vendor cannot say in one sentence where your data goes, we do not put them in front of you.
  • The worrysoftware that guesses, next to the books. What we do: we recommend automation only where a wrong answer is cheap and easy to catch, and you keep a named person of your own on anything that needs judgment. The tool drafts. The person approves.
  • The worrythe person who knows how it really works leaves, and none of it is written down. What we do: that person maps the job with us, and the map stays in the building. They keep the job and lose the retyping.
  • The worrytoo much time to learn, too much effort to manage, too much guesswork to trust. What we do: one job at a time, a working rule the team helped write, and no new tool where a setting in the old one will do.
(WHY US)

Why trust an advisor on AI at all.

The forums say AI consultants are the blockchain consultants of a few years ago. We understand the suspicion. Our answer to it is a number written down before anything is bought, agreed by the person who does the job today, and checked again afterward, so the answer is allowed to be no.

We learn your business before we name a job, and the first thing we do on any of them is count instead of build. When something does need building, we put several providers in front of you rather than one, bring their engineers into the room for the technical discussion, and you choose. The provider you choose does the work, and we stay at the table through it.

Whatever gets built lives in your accounts, under your logins, with the rules written down beside it in a document you own. We read the terms and the contract before you sign, and the renewal date goes on the same list as every other date we track for you.

Nothing depends on a login only we hold. We ask the provider to build it so your team can switch it off and go back to the old way, and when the provider needs chasing, we escalate with them on your behalf.

AI adoption is mostly a workplace problem and a security problem. The working rules and the sign-in protection get looked at alongside the automation, by the same person, so it fits how you already run instead of becoming a third project.

An advisor on AI for a small business is there to name the one job to start with, count it honestly, and stay on the phone every week until the count says it worked. The person you meet on the first call is the person who stays.

(WHERE IT WORKS)

Where the hours usually hide.

Business process automation works on narrow, repetitive, rule-bound work, and it fails on work with too many exceptions. The wins owners talk about are boring and specific: purchase orders processed, orders moved into accounting, less typing.

The question owners ask is where AI could reduce friction without creating a bigger mess. Most of what gets sold as AI for small business is workflow automation, and it starts with jobs like these.

  • Supplier invoices and purchase orders read, matched, and posted to the accounting system, with a person approving anything that does not match.
  • A shared inbox sorted, tagged, and routed before anyone opens it, so nobody spends the first hour sorting.
  • Quotes and proposals drafted from your own price list and past jobs, for a person to check and send.
  • Call notes and meeting follow-ups written up and filed where the team will find them.
  • Data moved between two systems that do not talk to each other, the job somebody does today by retyping.
  • The report somebody rebuilds by hand every Monday morning.
  • What we say no to. customer-facing decisions with nobody checking, the kind that end up in the trade press, work the business cannot describe as a rule, and any job where a wrong answer costs more than the hours it saves.
(What usually goes wrong)

We have seen this before.

  1. A pilot that is still a slide a year later.
  2. A demo that looked good, so it went straight to production.
  3. The last 20 percent that turned into a tar pit.
  4. An afternoon spent checking and rewriting what the tool wrote.
  5. Legal said no, and nobody could say what the thing does with the data.
  6. The one person who knew every exception left, and the exceptions left with them.
(Straight answers)

Questions people ask about this.

All the straight answers

I don't see the value over ChatGPT. Why would we need you?

Often you would not, and we say so. One person on a forum put it well: his tool is maybe 30 percent wrong, and he keeps using it because it solves problems quickly and cheaply. If that is you, one person typing into ChatGPT or Copilot and fixing what it gets wrong, keep doing that and leave us out of it. Workflow automation earns its keep when the same job runs many times a week, pulls from your own systems, and needs a record of what happened and who approved it. That is where we start. We learn the job, count it in numbers you already track, put more than one provider in front of you, bring their engineers to the table, and you choose. The same person stays on the phone every week until the count says it worked, and nobody calls it a win before then.

Another AI vendor calls every five minutes. How do we tell who is real?

Ask three things and watch what happens. Ask which one job in your business they would automate first, and notice whether they ask about your business before they answer. Ask how they would measure it, in whose numbers, and who checks the footnote. Ask what happens when the tool is wrong, and who catches it. The first person to check the footnote wins the argument.

We already ran an AI pilot with nothing to show. Why would this be different?

Pilots tend to stall for the same few reasons. Nobody said what they wanted the AI to do. The demo got promoted to production on a good feeling. The last 20 percent became a tar pit. And nobody had a baseline to argue with, so nobody could say what had changed. We start at the other end: one job, a count before anything is built, the smallest thing the provider's engineers could build that would do the job, and the old way kept running beside it until the count is in. If the count does not move, it stops and we say so, and you keep the write-up.

Legal said no. Is that the end of it?

Usually it is the start, because legal said no to a tool nobody had described to them. So the first thing we write with you is the rules document, and it holds more than the four lines about what the tool may read, write, and never see: who holds the data and where, how long anything is kept, who can switch the tool off and how, what gets logged so a decision can be traced later, and who answers for a bad output that slips through. Legal, the owner, and the person who runs the job all read it before anything runs. Sometimes the answer is still no. Then the document is still worth having, because it says exactly why, and what would have to change for the answer to be yes.

Will this push out the one person who really knows how the process works?

No, and we would not recommend building it without them. That person knows every exception, and most of those exceptions live in their head. They map the job with us, and they decide what the software may do on its own and what comes to them first. The map is kept current the same way the automation is: each time a new exception shows up, it gets added, and that person owns the change. What comes off their desk is the copying and pasting. If a tool would only pay off by pushing that person out, we tell you it is the wrong tool.

Is our data going to end up training somebody's model?

Not if the tool lets you say no, and we only recommend the ones that do. The same tool often comes in two tiers. The consumer tier is the free or cheap one a person signs up for with a personal email, and its terms usually let the vendor keep and learn from what gets typed in. The business tier is bought by the company, costs more, and usually comes with a written promise that your data is not used for training and can be deleted when you ask. The trouble tends to start when the first tier gets used for work. We read the terms of the tier you are on before you sign, the provider sets the tool up inside accounts you own, and we tell you plainly when a tool has no way to say no.

Do we have to buy new software first?

Usually not, and we check before you spend anything. Many businesses already pay for tools that can do the first job: the automation built into Microsoft 365 or Google Workspace, or the connectors that come with the accounting system. We look at what you own before anything new goes on the table. If a new tool really is needed, you see more than one, you choose, the account and the contract are in your name, and before you sign you know what it costs per month, what it replaces, when it renews, and how you get your data out if you stop using it.

(Get a second opinion)

Forward the pitch before you answer it.

Send over the vendor proposal, or the pilot report with no numbers in it, or a plain description of the job you want off somebody's desk. A senior person reads it, and within two business days you have thirty minutes on the phone: which job we would start with, what the count would look like, and whether it is worth doing at all. No charge, no pitch, and you will not hear from us again unless you ask. If the hours come back, they are for the work only you can do, and for lunch.

Get a second opinion