Clarkes.Team
(866) CLARKE6 Get Started Client Portal
All services AI and workflow automation

AI and workflow automation for small businesses It ran at 3am.
Nobody had to think about it.

Getting your team onto the assistants is the easy part. The work that pays for itself is the automation nobody has to remember to run — and the reason to have engineers build it is that something running unattended needs watching.

Request a quote How we keep it safe

The first conversation costs nothing, and nothing that calls a paid model goes live without a cost ceiling you agreed to.

What we do

Five ways automation earns its place

From the repetitive work between the tools you already pay for, through to staying responsible for it once it runs without anybody watching.

Workflow automation

Removing the repetitive work between the systems you already run.

Most of the manual work in a small business is not hard, it is just nobody’s job to stop doing it: copying an order into the accounting system, chasing a form that never arrived, re-keying the same address into three tools, assembling the same report every Monday. It survives because it is invisible until somebody measures it.

We find that work, agree which parts are worth automating, and build the automation that does it — then stay responsible for it once it is running unattended.

  • Connecting the tools you already pay for, so data stops being re-keyed
  • Scheduled work that used to be somebody’s Monday morning
  • Approval and hand-off steps that currently live in someone’s inbox
  • Alerts and notifications that fire on the event rather than on a person remembering
  • Reports assembled and delivered without anybody building them
  • Replacing the spreadsheet that holds a process together
Request a quote

Document and data processing

Reading what arrives, and routing it where it belongs.

Work arrives as documents and messages: invoices, purchase orders, application forms, inbound email, support tickets, scanned paperwork. Somebody opens each one, decides what it is, pulls out the few fields that matter and puts them somewhere else.

This is the work current models are genuinely good at, and it is the easiest kind to measure honestly — you already know how many arrive and roughly what each one costs you in attention. We build the intake, the extraction and the routing, with a review step wherever being wrong would be expensive.

  • Intake from email, upload, a form or a shared folder
  • Extracting the fields that matter into your own systems
  • Classifying and routing by type, urgency or owner
  • Flagging the exceptions for a person instead of guessing
  • Reconciling what arrived against what was expected
  • A record of what was read, what was extracted and what a person changed
Request a quote

AI assistants on your own data

Answers from your documents and systems, not from the open web.

A general assistant knows nothing about your pricing, your contracts, your procedures or last quarter’s numbers, which is why the useful version is pointed at your own material. The questions a team actually asks are specific: what did we agree with this client, what is the current process for this, which of these is covered.

That means deciding what the assistant may see, keeping it current as the underlying documents change, and being clear with the people using it about what it is allowed to answer on its own. We also set the accounts and access up properly, which is usually the first thing a team needs and rarely the last.

  • An assistant grounded in your documents, policies and records
  • Access rules, so it only answers from what that person may already read
  • Keeping it current as the underlying material changes
  • Answers that cite the source, so they can be checked
  • Accounts, access and licensing set up properly for the team
  • Practical training for the people who will use it daily
Request a quote

AI inside software you already run

Model-backed features in your own application, built to be operated.

Where you already have an application, a portal or a storefront, the automation often belongs inside it rather than beside it — a search that understands what was meant, a draft reply prepared for an agent, a classification applied the moment a record is created.

Adding a paid model to a route inside your own software is a different engineering problem from using an assistant: it runs on your infrastructure, on your budget, at whatever volume your users generate. That is the work we already do on the development and infrastructure side, which is why it sits here rather than being somebody else’s integration.

  • Model-backed features added to an application you already run
  • Search and classification that work on your own data
  • Drafting and summarising inside the tool your team already has open
  • Cost ceilings and rate limits on every route that calls a paid model
  • Choosing a model sized to the task rather than the largest available
  • Fallback behaviour for when the provider is slow, down or wrong
Request a quote
The part most AI work skips

Automation operations

Staying responsible for the automations once they run unattended.

An automation that works on the day it ships is not the same as one you can rely on a year later. The tools it connects change their APIs, a model is retired or repriced, a provider has an outage, the volume doubles, and an edge case nobody modelled starts failing quietly at three in the morning.

This is the part most AI work skips, and it is the reason a business ends up trusting a process that has silently stopped running. Operations covers that as a standing responsibility rather than a series of surprises: the automations are watched, kept working as the services underneath them move, and fixed by the people who built them.

It runs as a monthly arrangement scoped to your automations, quoted alongside the build or after a review of something you already have. It is not metered by ticket.

Request a quote
  • Monitoring, so a failure is noticed by us rather than reported by you
  • Keeping up with provider API, model and pricing changes
  • Cost monitoring against the ceilings agreed up front
  • Fixing the exceptions that only appear at real volume
  • Incident response when an automation or a provider fails
  • Changes as the process changes, because a process always changes
How we choose

The simplest thing that will hold

A great deal of useful automation does not need anything written. Where an off-the-shelf platform will do the job reliably, that is what we recommend, set up and document — and we will tell you so even though it is the smaller piece of work.

What those platforms do not do well is the awkward part: an exception that needs judgement, a system with no usable integration, a volume that makes per-task pricing absurd, or a failure that has to be handled rather than retried forever. When a workflow reaches that line, we write the code, and we are not incentivised to pretend the line falls earlier than it does.

How we keep it safe

Four things you get in writing

An automation that runs without supervision can fail in ways a person never would. These are the four commitments that come with every one we build.

  1. A cost ceiling, agreed up front

    Anything that calls a paid model is metered and capped at a figure agreed before it goes live. Usage-priced services are the one place where a bug is also an invoice, and an endpoint that can call a model without limit is a bill waiting to happen rather than a theoretical risk. You are told what the ceiling is, and told when it is approached.

  2. Your accounts, your keys, your data

    Before anything is built you get it in writing: which accounts are in your name, who holds the keys, whose payment method is on each service, which of your data leaves your systems, and what the provider does and does not retain. Where a provider’s terms are not good enough for the data in question, that rules the provider out rather than becoming a footnote.

  3. Automations fail loudly

    The dangerous failure is not the one that stops, it is the one that keeps appearing to work. Every automation we build is built to surface its own failures — nothing retries into silence, nothing swallows an error, and nothing quietly drops the work it was given. If it stopped, you will know it stopped.

  4. A person stays in the loop where it matters

    Nothing that spends money, commits you to something or carries a legal consequence runs unreviewed by default. Where a step is automated end to end, that is a decision taken deliberately, with you, once the behaviour has been observed on real work — not the starting assumption.

The stack

What we build with, and run in production

Models are chosen per workload rather than once per company. Each name with a guide behind it links to it.

Models

Chosen per task, and sized to it rather than to the headlines.

Automation platforms

Where an off-the-shelf platform is the right answer, these are the ones we set up and document.

Running something not listed here? Tell us what it has to talk to

Your apps, not just ours

We wire automations into the apps you already run

An automation is only useful where the work already happens. These are applications we have connected automations to — and the list is nowhere near the limit.

Work, tickets and helpdesk

Where the task, the ticket or the hand-off actually lives.

Asana, Jira, Trello, ClickUp, Zendesk, Intercom

Google Workspace

The inbox, the calendar and the sheet most small businesses already run on.

Gmail, Google Calendar, Google Drive, Google Sheets

CRM, finance and payments

Where the money and the customer record live, and where mistakes are expensive.

HubSpot, Salesforce, QuickBooks, Xero, Stripe

Docs, data and messaging

The connective tissue an automation passes through on its way somewhere.

Slack, Notion, Airtable, Dropbox, Box, MailChimp, Twilio

Also wired in regularly: Microsoft 365, Outlook, Teams, SharePoint, monday.com, Pipedrive.

Running something that isn’t here? That is the normal case rather than the exception — most businesses have at least one system nobody else has heard of. Tell us what you run

How it works

How an engagement runs

One automation in real use before a programme of them is agreed, and a person watching it until it has earned the trust.

  1. 01

    Conversation

    We talk through where the manual work actually is, what you have already tried, and whether any of it is worth automating yet. Sometimes the answer is that it is not, or not before something else is fixed. This conversation costs nothing.

  2. 02

    Assessment

    A written, prioritised view of the candidates: what each one would take off your team, what it would cost to build and to run, what could go wrong, and which one to do first. It is scoped and quoted as its own piece of work, and it is yours to act on with or without us.

  3. 03

    Build the first one

    One automation, built and in use, before a programme of them is agreed. You learn more from a fortnight of a real automation running on real work than from any amount of planning, and it is a far cheaper place to discover that the process was not what everyone believed.

  4. 04

    Go live with a person watching

    A new automation starts with its review step on and its cost ceiling set, running alongside the manual process rather than replacing it on day one. We take the training wheels off once the behaviour has been observed on your own work, and we decide that together.

  5. 05

    Operate it

    Once it is unattended it needs an owner: monitoring, cost tracking, keeping up with the providers underneath it, and fixing the exceptions that only appear at volume. That runs as a monthly arrangement scoped to your automations, and it is optional — the automations are yours either way.

Where the line is

What this isn’t

Four things we will not sell you, because each one is either someone else’s work or a promise nobody can keep honestly.

Training or building a model from scratch
We build on models from established providers rather than training our own. A business at this scale is almost never better served by a bespoke model than by a good one used well, and we would rather say so than sell the more impressive-sounding version.
Strategy without implementation
We do not sell a presentation about what you could do. The assessment exists to decide what to build and in what order, and it is written to be acted on — by us or by anyone else you choose.
An accuracy figure we have not measured
We will not quote a percentage for how accurate an automation will be on work we have not seen. Where accuracy matters we measure it on your own data during the build, agree what is good enough, and design the review step around what is left.
Automating a process nobody has questioned
Some of the work we find should be removed rather than automated, and some should be fixed in the system that creates it. Automating a bad process makes it faster and harder to see. Expect to be told when that is what we are looking at.
Before you ask

Questions worth asking first

We are already using ChatGPT and Claude. What is different about this?

Those are assistants: a person opens them, asks for something and uses the answer. That is genuinely useful, and getting a team properly set up on it is work we do. An automation is the next step — it runs without anybody opening anything, on a schedule or when an event happens, and it writes its results back into the systems you run. The difference that matters commercially is that nobody has to remember to do it, and the difference that matters operationally is that something unattended needs watching.

How do we know what to automate first?

That is what the assessment is for. It looks at where the repetitive work actually is, what each candidate would take off your team, what it would cost to build and to run, and what could go wrong — then puts them in an order. The first build is usually the one that is well understood and boring rather than the one that is most impressive, because the first automation is also how everyone learns to trust the rest.

What stops this running up a large bill?

A ceiling, agreed before it goes live, on every route that calls a paid model, plus metering so the figure is visible rather than discovered on an invoice. We also size the model to the task: a smaller, cheaper model is frequently sufficient for classification and extraction, and using the largest available model everywhere is a common and expensive default. Usage-priced services are the one place where a bug is also an invoice, and we treat them that way.

Where does our data go, and is it used to train anything?

You get that in writing before anything is built: which of your data leaves your systems, which provider receives it, what that provider retains, and what their terms say about training on it. Where a provider’s terms are not acceptable for the data in question, that rules the provider out rather than becoming a footnote. Accounts and keys are in your name wherever the service allows it.

What happens when the automation gets something wrong?

It is designed on the assumption that it will. Anything consequential keeps a review step, exceptions are flagged for a person rather than guessed at, and failures surface rather than retrying into silence. Where accuracy matters we measure it on your own data during the build and agree what is good enough before it is relied on — which is also why we will not quote you an accuracy figure for work we have not seen.

Which model do you use?

Whichever fits the task and your data policy — we build with Claude, OpenAI and Google Gemini. That decision is made per workload rather than once per company, because the models differ in cost, speed and what they are good at, and the right answer for classifying a form is rarely the right answer for drafting a reply. We keep that choice changeable, so a repricing or a retirement at one provider is a change rather than a rebuild.

Can you take over automations somebody else built?

Yes, and it is a normal engagement. We start by reading what is there — what it does, what it connects to, whose accounts and keys it runs on, where it fails and what it costs to run — and give you that in writing. Undocumented automations built by someone who has since left are a common reason businesses come to us, and the first job is usually to find out what is still running.

Who owns what gets built?

You do. Work built specifically for you becomes yours on full payment, the same as on any development engagement, and the accounts it runs on are in your name wherever the service allows it. The exception is the general-purpose tooling and know-how we bring with us, which stays ours. If the arrangement ends, you are left with working automations and the documentation for them rather than a dependency.

How do you scope and price this?

The first conversation costs nothing. The assessment is scoped and quoted as its own piece of work, with a written deliverable you own. Builds are quoted per automation or per engagement once there is a plan, and ongoing operations is a monthly arrangement scoped to the automations you end up running — not metered by ticket.

Do you also run the systems these automations depend on?

Usually, and it tends to be the same conversation. Servers, cloud environments and applications are sold as their own services, so an automation we build can sit on infrastructure and software the same team operates — which matters most during an incident, when there is no handover boundary in the middle of it.

Something not covered here? Talk to an engineer

Tell us where the repetitive work is

You do not need to know what to automate, or whether any of it is worth automating yet — that is what the first conversation is for, and sometimes the answer is that something else should be fixed first. It costs nothing either way.

Request a quote All services