<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
<channel>
<title>Automancer — Field Notes</title>
<link>https://automancer.uk/field-notes/</link>
<description>Practical AI and workflow automation for UK small businesses. Cut admin, reduce errors, and improve operations with Automancer.</description>
<language>en-gb</language>
<atom:link href="https://automancer.uk/field-notes/rss.xml" rel="self" type="application/rss+xml" />
<item>
<title>Self-storage software in the UK: what to check before you sign</title>
<link>https://automancer.uk/field-notes/self-storage-software-what-to-check-before-you-sign</link>
<guid>https://automancer.uk/field-notes/self-storage-software-what-to-check-before-you-sign</guid>
<pubDate>Mon, 24 Aug 2026 00:00:00 GMT</pubDate>
<description>Before you renew a self-storage platform, check three things: how it charges you as you grow, what your customers can do online, and how you get your data out.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Self-storage is a good business partly because it is boring. Units, dates,
direct debits, the occasional padlock. The software you rent to run it is where
the interesting money quietly goes.

This is not a case study. We have not shipped a storage platform, and I am not
going to pretend otherwise. It is the list I would work through if you asked me
to look at yours.

## What does a small self-storage operator actually need online?

Five things. Live unit availability, so a customer can see what is free without
ringing you. Prices they can read without asking. A reservation that takes a
deposit or a first payment there and then. ID and agreement handling that
produces a signed, stored document without anybody finding a printer. And
reporting you trust on a Monday morning: occupancy, arrears, who is due to
move out.

Everything else on a vendor's feature list is a nice-to-have until those five
work properly. Dynamic pricing engines and marketing modules are very
persuasive in a demo and worth nothing at all if your move-in still needs a
phone call.

## The monthly price is not the price

Storage platforms tend to charge in one of three shapes: a flat monthly
platform fee, a monthly fee plus a percentage of the payments taken through
the system, or a per-unit fee that steps up in bands as you add units. Which
one you are on is in the contract, not usually on the pricing page.

The flat fee is predictable and the other two are a share of your growth. A
per-transaction cut is the one that surprises people, because it grows exactly
when the business is going well. Sell more, pay more, forever, for software
that costs the vendor no more to run at your higher volume than it did at your
lower one.

So do not compare headline monthly fees. Rebuild the whole-year cost at the
occupancy you expect to be at in two years, and again at the one you are
frightened of, then compare those. Vendors rarely make that easy to compute
and they are not obliged to. It is not magic and it is not even hard: a
contract, a spreadsheet and half an hour.

## Ask what happens when you want to leave

Three questions, in writing, before you sign anything. The answers tell you
more than the demo does.

- **Can I export my own data, whenever I want, in a format I can actually
  use?** Usable means a spreadsheet or a data file with your customers, units,
  agreements and payment history in it. A PDF report is not an export. If the
  answer involves a support ticket, a fee, or a phrase like "we can look at
  that", you now know what leaving costs.
- **What happens to the price at renewal?** Ask for the uplift mechanism, in
  the contract, not a reassurance on a call. A cap you can point to later is
  worth having.
- **What is the notice period, and what happens to live agreements and
  in-flight payments if I serve it?** Your customers keep their units either
  way. Somebody has to make that true, and you want to know who before it
  matters.

None of this is hostile. It is the same thing any decent vendor has already
thought about. But your customers will come to you when something goes wrong
with their data, not to the company whose logo is in the corner of the admin
screen, so the answers need to be yours to give.

## Rent it, until renting stops making sense

For most independent operators with a site or two, renting is the right answer
and I would not pretend otherwise. Somebody else handles the payment
integrations, the security patching and the phone-line when it breaks at 8pm,
and that is worth real money.

Custom software earns its place at a specific moment: when the percentage cut
has grown past what running your own would cost, or when the platform cannot
do the one thing your business actually depends on and the roadmap answer is
"not this year". That is the calculation a UK plastics manufacturer went
through before we built their [trade
portal](/work/manufacturer-trade-portal). Account-specific pricing that used to
live in people's heads is now computed by a rules engine, with ordering,
production and dispatch in one flow, Phase 1 signed off in April 2026.
Different sector, same question: at what point does renting someone else's
approximation cost more than owning the real thing?

Ours are published, so you can do that sum without booking anything. An
Automation Opportunity Audit is from £450, and a System / Agent Build is from
£4,500. They are on the [services page](/services) with everything else.

## What I'd actually do about it

Find your current contract and pull out three numbers: the monthly fee, the
percentage cut if there is one, and the notice period. Most operators know the
first, guess the second, and have never read the third.

Then rebuild last year's total cost at next year's occupancy. If the answer
grows faster than your revenue does, you have found the thing worth
negotiating at renewal, and you have a year to do it in rather than a fortnight.

While you are there, run the five-things list against your own website as a
customer would. Availability, price, reserve, sign, report. If a prospective
customer cannot get from "have you got a 50 square foot unit" to "it's booked"
without speaking to a human, that is costing you more than any contract term
on this page.

If you want a second pair of eyes on it, that is what an Automation
Opportunity Audit is for: from £450, credited in full against any project you
go on to do, and you keep the plan either way. Or just fill in [the
form](/contact). Waseem reads it himself and emails you back, we promise a
meeting within one week, and a human makes every decision along the way.

*We build software, we are not solicitors, and none of the above is legal
advice. It is how we read a software contract before recommending one.*
]]></content:encoded>
</item>
<item>
<title>New business, no website: the UK compliance checklist</title>
<link>https://automancer.uk/field-notes/new-business-website-legal-compliance-checklist</link>
<guid>https://automancer.uk/field-notes/new-business-website-legal-compliance-checklist</guid>
<pubDate>Mon, 17 Aug 2026 00:00:00 GMT</pubDate>
<description>What a new UK company's website needs: company details in the footer, a real email address, an up-to-date privacy notice, and an honest cookie banner.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[You can incorporate a UK company online, before lunch, without speaking to
anybody. Working out what your website is then expected to carry takes rather
longer, which is why most new businesses skip it and hope.

We build sites for brand-new companies, so this is the list we work through
every time. It is not legal advice, and we are not the people to give you any.
It is what a working site needs in place before you start pointing traffic at
it.

## What does a new UK business website need to include?

Four facts about the company: its registered name, the part of the UK where it
is registered, its company number, and its registered office address. A real
way to reach you: your name, a geographic address, and a working email address,
not only a form. A privacy notice, if the site collects any personal data at
all, which a contact form does. And a cookie position that matches what your
analytics is actually configured to do. Worth knowing what is not on that list:
nothing obliges a business website to publish terms and conditions. They are a
good idea, not a box to tick.

## The footer nobody tells you about

The four company facts have to be available on the site. Nobody prescribes
where, so a site-wide footer or a clearly signposted legal-information page
both do the job, as long as a human can actually read it without a magnifying
glass.

It is tempting to file this under tidiness. It is not. Leaving it off is an
offence in itself, and the sharper risk sits in the contracts you make while
in breach: the other side can ask the court to throw out your claim on one. A
court can still let the case through where the defendant was not actually
prejudiced, so it is a risk rather than a certainty, but it is a risk you are
running on your own unpaid invoices for no reason at all. No incantation
required to avoid it: four facts, in a footer, ten minutes.

## The requirement almost nobody has heard of: a real email address

A commercial website is expected to publish a working email address, in a form
that is easy to find and stays put. A contact form on its own is generally not
treated as enough. The form is fine as the fast route, but a published address
needs to sit alongside it.

This is usually read to cover ordinary brochure sites too, not just online
shops, which is why so many otherwise tidy small-business sites are quietly
offside. It also has more teeth than it used to: since April 2025 the
Competition and Markets Authority can enforce these consumer-facing duties
directly, after two decades in which more or less nobody did.

## The data rules moved twice in 2026

If your site has an enquiry form, you are collecting personal data, and you
need a privacy notice that says who you are, what you are doing with the data,
your legal basis, who else sees it, how long you keep it, and what rights
people have. In plain language, where you collect the data, not buried three
clicks away.

One line changed in June 2026. Your notice now has to tell people they can
complain to you directly and not only to the Information Commissioner, and you
have to actually handle those complaints: make it easy to raise one,
acknowledge it inside a month, and respond without dragging it out. If your
notice was written before this summer it is missing a line it is now supposed
to carry. That is a five-minute edit, and it is the single most common thing we
find out of date on an existing site.

Cookies moved earlier in the year, so check the date on anything you read about
them, including this. You may have heard that analytics no longer needs
consent. It is narrower than that. The exemption covers analytics used only to
collect statistics about how your own site is used so you can improve it, where
the data is not passed on to anyone else, you tell visitors clearly what you
are doing, and you give them a simple free way to say no. Analytics that feeds
advertising, measures conversions for an ad platform, or follows individual
visitors around still needs consent, so a default install with the ad features
switched on is not covered. The penalty ceiling for getting this wrong went up
sharply in 2026, which is a good reason to know which of those two things your
tag is doing.

## From nothing to live and compliant, and why "later" is a bad plan

We took a brand-new UK travel agency from zero web presence to a live,
compliant marketing site: services sections, a tested working enquiry form,
WhatsApp and phone contact wiring, and the required trading-disclosure footer.
We handled domain purchase, DNS, HTTPS hosting and interim email routing too,
so they had a working front door and a working inbox from day one. That last
part is not incidental. The email requirement above is impossible to satisfy if
nobody has decided who reads the inbox yet. The write-up is in [the fast
websites case study](/work/fast-small-business-websites), and it is hand-built,
so it costs essentially nothing to run.

"We'll add the legal stuff later" fails for a dull reason. Later is when you
have traffic. Disclosures, the privacy notice and cookie behaviour are cheapest
while the site is being built, because they are decisions about structure.
Retrofitting a consent mechanism onto a live site, or working out after the
fact whose data you have been collecting since March, costs real money and
produces a worse result.

## What I'd actually do about it

Open your own site and check three things. Are the four company facts in the
footer. Is there a real email address, not just a form. Does your privacy
notice mention the right to complain to you as well as to the ICO. If you
incorporated recently, all three are probably missing, and all three are an
afternoon's work rather than a project.

Leave the cookie question until you know what your analytics is actually
configured to do, because that determines the answer and nothing else does. And
whether you owe the ICO the annual data protection fee is worth ten minutes on
their registration self-assessment rather than a guess in either direction.

We publish real from-prices for our automation work on our [services
page](/services), starting with an Automation Opportunity Audit from £450, and
we would rather tell you one honest page is enough than sell you eight. If you
want a straight answer about your own site, fill in [the form](/contact).
Waseem reads it himself and emails you back, we promise a meeting within one
week, and a human makes every decision along the way.

*We build websites, we are not solicitors, and none of the above is legal
advice. It describes how we set up sites for new UK companies as at August
2026. If your situation is unusual, or a decision here carries consequences you
care about, take proper advice on it.*
]]></content:encoded>
</item>
<item>
<title>Credit hire firms: the website compliance and trust checklist</title>
<link>https://automancer.uk/field-notes/credit-hire-website-compliance-trust-checklist</link>
<guid>https://automancer.uk/field-notes/credit-hire-website-compliance-trust-checklist</guid>
<pubDate>Mon, 10 Aug 2026 00:00:00 GMT</pubDate>
<description>What a UK credit hire website needs: the registration details that belong in the footer, the trust signals that win the enquiry, and the SEO basics templates skip.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Someone has just been in a crash that wasn't their fault, and over the next hour
three different people will tell them to be careful who they trust. Then they
find your website.

## What does a credit hire firm's website actually need?

A credit hire website needs four things: a plain explanation of how a non-fault
replacement vehicle works and who pays for it, visible proof that you're a real
registered UK company, the registration details that belong in the footer, and
structured data so search engines know you're a local business serving a specific
area. Design comes after all four, not before.

That list is short because the job is narrow. Nobody browses credit hire sites
for pleasure. Your visitor arrived from a search or a garage's recommendation,
they have one question, and they'll decide in about a minute whether you look
like a firm that answers the phone.

## Trust does more work here than design does

In most trades a website's job is to look credible. In this one it has to defuse
suspicion that arrived before the visitor did. Your customer has probably already
been offered a courtesy car by the other side's insurer, warned about hire
charges by somebody, and asked to sign an agreement on the worst day they've had
all year. None of that is your fault, and all of it is yours to answer.

One thing I won't do here: tell you what your obligations are on the hire
agreement itself. That's your solicitor's territory and it moves. This is about
the shop window.

What the shop window has to carry:

- **A named, registered company.** Registered name, company number, where it's
  registered, registered office. Not a first name and a mobile number.
- **Plain words about money.** Who pays, when, and what happens if the claim
  isn't accepted. Vagueness on this point reads as a catch, because the reader has
  already been told there's one.
- **A phone number a human answers**, in the header, tappable, plus whichever of
  WhatsApp or SMS your customers actually use. Nobody fills in a contact form
  from the hard shoulder.
- **A place.** People want to know roughly where the vehicle is coming from and
  whether you cover their town.

## The footer most small sites get wrong

Here's the list we work through when we build a site for a UK limited company:
the company's registered name, its registered number, the part of the UK where
it's registered, and the address of its registered office. It's a footer, not a
project, and leaving it off costs you credibility long before it costs you
anything else. If your own site is missing any of it, that's worth a conversation
with your accountant or solicitor as well as with whoever built the site.

The footer matters twice as much in this sector. A customer who has just been
told to be careful about credit hire will go looking for exactly this sort of
detail, and an honest firm with nothing in its footer gives them no way to tell
the difference. We built that footer into a new travel agency's site when we took
them from zero web presence to live, because a brand-new company is precisely the
sort of business nobody has ever thought to mention it to. It's the cheapest
credibility you'll ever buy.

## Getting found: the boring layer that decides it

The part of your site that determines whether you turn up for "accident
replacement vehicle near me" is invisible on the page. It's structured data, a
sitemap and a robots file, and templates routinely skip all three.

Structured data is the closest thing web development has to an incantation: a
block of text no visitor ever sees, which tells a search engine, and increasingly
an AI assistant answering the question instead of a search engine, precisely what
your business is, where it operates and how to contact you. It's not magic. It's
a small, well-formed block of machine-readable text, and its power comes entirely
from the fact that most sites can't be bothered to include it.

For a local credit-hire firm we built a sharp single-page marketing site with the
technical fundamentals baked in: structured data so search engines understand the
business, plus the SEO basics, sitemap, robots and the rest, done properly rather
than skipped. Live, fast and findable. It's hand-built and costs essentially
nothing to run, with no monthly platform fee quietly draining the account. The
write-up is in [the fast websites case study](/work/fast-small-business-websites).

Fast and cheap didn't mean amateur. It meant we left out the parts that weren't
the job, rather than the parts that were.

## The checklist: run this against your own site today

1. **Trading disclosures in the footer of every page.** Registered name, company
   number, place of registration, registered office address. Open your own site
   and look. Most people find nothing.
2. **One clear sentence explaining what credit hire is** and who pays, near the
   top, before any form.
3. **What happens if the claim isn't accepted**, in your own words, rather than
   left for the customer to imagine.
4. **A tappable phone number in the header**, plus the messaging channel your
   customers actually use.
5. **Your town and service area written in the page text**, not only inside a map
   embed. If the area exists nowhere in words, "near me" searches can't match it.
6. **Structured data describing you as a local business**: name, address, phone,
   hours, area served. Ask whoever built the site to show you it's there.
7. **A sitemap and a robots file.** Two files. Check that
   yoursite.co.uk/sitemap.xml actually loads.
8. **Test your own enquiry route** from a phone you don't normally use, and time
   how long the reply takes. That number is your real conversion rate.

## What I'd actually do about it

If you're missing items 1, 6 and 7, you don't need a new website. You need an
afternoon of someone competent, and the work is cheap because it's small and well
understood.

If you're missing 2 and 3, the fix is writing rather than code, and it's the
highest-value writing in the business. Answer the money question before the
customer has to ask it, because being asked to trust someone who won't answer it
is exactly what they were told to watch for.

And if you have no site at all, don't start by shopping for a design. Write down
the three things a visitor must be able to do, which here is usually understand
what credit hire costs them, believe you're real, and reach you in one tap. Get
that live, then improve it with real traffic in front of you.

We publish real from-prices for our automation work on our [services
page](/services), starting with an Automation Opportunity Audit from £450, and
we'd rather tell you a single page is enough than sell you eight of them. If you
want a straight answer about your own site, fill in [the form](/contact). Waseem
reads it himself and emails you back, we promise a meeting within one week, and a
human makes every decision along the way.

*We build software. We are not solicitors, and none of this is legal advice. For
that, ask someone qualified to give it.*
]]></content:encoded>
</item>
<item>
<title>How much should a small business website cost in 2026?</title>
<link>https://automancer.uk/field-notes/small-business-website-cost-2026</link>
<guid>https://automancer.uk/field-notes/small-business-website-cost-2026</guid>
<pubDate>Mon, 03 Aug 2026 00:00:00 GMT</pubDate>
<description>A small business website should be a one-off cost, not a monthly rent, and not a five-figure project. What you are really paying for, and what to check.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Ask five web agencies what a small business site costs and you will get five
numbers, four of which only arrive after a discovery call. Here is the honest
version, including the part of the bill most quotes quietly leave out.

## How much should a small business website cost in 2026?

A marketing site for a small UK business should be a one-off cost rather than a
monthly rent, and it should not be a five-figure project. The number you are
quoted for the build is only half the question. The other half is what the site
costs you every month for the next three years, and that second figure usually
decides whether you got a good deal.

A site built once and hosted for essentially nothing will cost you less by year
two than a cheaper one with a subscription bolted to it, and the gap widens
every month you keep trading. So the useful question is not "what does a
website cost". It is "what does this website cost me to keep".

## The two bad options most small businesses are offered

The first is a web agency with a five-figure quote and a three-month timeline.
For a business selling complex products online with stock, payments and a
warehouse behind it, that can be entirely fair. For a new company that needs a
credible front door and a working enquiry form, it is a lot of money and a lot
of waiting for something that should exist by the end of the week.

The second is a drag-and-drop builder that charges you rent forever and still
looks like everyone else's. It gets you live quickly, which is real value. But
you are renting the shop window, the lights stay on only while you keep paying,
and the platform owns the thing your customers find you through.

Neither is a scam. They are just both priced for someone who is not you.

## What you are actually paying for

Most of the cost difference between a good small site and a bad one is invisible
on the homepage. Three things are worth paying for, and templates routinely miss
all three.

**The footer.** Four details belong in it: registered name, company number, place
of registration and registered office address. It is the list we work through on
every limited company site, and a new business is exactly the sort of business
nobody has ever mentioned it to. It is a footer. It takes minutes to do properly
and it is embarrassing to be missing. Check any quote includes it.

**The technical fundamentals.** Structured data so search engines and, these
days, AI assistants can tell what your business actually is and where it
operates. A sitemap and a robots file, done properly rather than skipped. None
of this is glamorous and none of it shows up in a design mock-up, which is
precisely why it gets dropped.

**A front door that works.** An enquiry form that has been tested by an actual
human sending an actual enquiry. Contact routing that reaches you on the channel
your customers use. A domain, DNS and HTTPS that someone else set up so you
never have to learn what a nameserver is.

## A real example: from nothing to live, in days

We took a new UK travel agency from zero web presence to a live marketing site:
services sections, a tested working enquiry form, WhatsApp and phone contact
wiring, and the trading-disclosure footer. We handled the domain purchase, DNS,
HTTPS hosting and interim email routing too, so they had a working front door
and a working inbox from day one.

For a local credit-hire firm we built a sharp single-page site with structured
data so search engines understand the business, plus the SEO basics done
properly rather than skipped.

Both are hand-built and cost essentially nothing to run. No monthly platform fee
quietly draining the account. The full write-up is in [the fast websites case
study](/work/fast-small-business-websites).

There is no sleight of hand in that. Hand-built static pages have no platform
tax to pay, so the running cost collapses to a domain renewal once a year. It is
not magic, it is just not paying rent on something you could own.

## Five questions to ask before you accept a website quote

1. **What does this cost me in year two?** Add up the build fee plus 24 months
   of every recurring line on the quote. Compare that total, not the headline.
2. **Who owns the site if I leave?** If the answer involves exporting to a zip
   file that does not run anywhere else, you are renting.
3. **Are the trading disclosures included?** If the person quoting you does not
   know what you mean, that is your answer about the rest of the detail.
4. **Is structured data, a sitemap and a robots file in scope?** These are cheap
   to include and expensive to retrofit into a template.
5. **When does it go live?** Days and weeks are reasonable for a marketing site.
   Three months usually means you are queued behind bigger clients.

## What I would actually do about it

If you are a new business with no site at all, do not start by shopping for a
price. Start by writing down the three things a visitor must be able to do:
usually understand what you sell, trust you enough to enquire, and reach you.
Anything that does not serve one of those three is scope you are paying for and
do not need yet.

Then get it live and improve it with real traffic in front of you. A modest site
that exists today beats a better one that launches in November, because the
better one is still a guess until someone visits it.

We publish real from-prices for our automation work on our [services
page](/services), and we would rather tell you a site is a small job than sell
you a big one. If you want a straight answer about your own site, fill in [the
form](/contact). Waseem reads it himself and emails you back, we promise a
meeting within one week, and a human makes every decision along the way.

*We build software. We are not solicitors, and none of this is legal advice. For
that, ask someone qualified to give it.*
]]></content:encoded>
</item>
<item>
<title>B2B trade portals: what to build first, and what to leave for phase 2</title>
<link>https://automancer.uk/field-notes/b2b-trade-portals-what-to-build-first</link>
<guid>https://automancer.uk/field-notes/b2b-trade-portals-what-to-build-first</guid>
<pubDate>Tue, 28 Jul 2026 00:00:00 GMT</pubDate>
<description>Phase 1 of a B2B portal should be the smallest thing your team can use on a Monday and trust. What to build first, what to defer, where to draw the line.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Every custom software project hits a moment where the wish-list meets the
calendar. How you handle that moment decides whether you get a working system
in a few weeks or a half-built one next year.

## Why big-bang launches go wrong for small teams

A big-bang launch is the one everybody pictures. Months of building, one
go-live date, the old way switched off on a Friday and the new way switched on
by Monday.

Large organisations can just about absorb that. They run both systems side by
side for a quarter, they have someone whose actual job is training, and if it
goes badly there is a fallback and a budget line for it. A team of twelve has
none of those things. Nobody has a spare afternoon to test a system that is not
live yet, so the testing happens on real orders in front of real customers.
There is no parallel run, because the same six people would have to do
everything twice. And the review arrives in one enormous lump: you are asked to
approve a system you have never used, on the day you start depending on it.

The quieter failure is what happens during the silent months in between.
Nothing to react to means every requirement stays a guess, and guesses drift.
By the time it lands, half of what you asked for in February is not what you
need in September, and nobody found out in time to say so.

## What should go in phase 1 of a B2B portal build?

Phase 1 should be the smallest version of the system your team could use on a
Monday morning and trust with real work. Not a demo and not a prototype: a
usable foundation that runs your main flow end to end, from the thing coming in
to the thing going out.

That means a thin slice through the whole process rather than a thick layer of
one part of it. A polished customer login with no order queue behind it is a
nice screen. An order that can be placed, priced, made, dispatched and turned
into a draft invoice is a business running on software, even with half the
reporting still missing.

The test is blunt. Can one of your people take a real job all the way through
without leaving the system to finish it off in a spreadsheet? If yes, that is a
foundation, and everything after it is an improvement on something that already
works. If no, it is not phase 1, it is a fragment, and you will be running two
systems until phase 2 lands.

## What we deferred on a real build, and why it wasn't a corner cut

For a UK plastics manufacturer and trade supplier, we built a trade portal
covering the order lifecycle: account-specific pricing, catalogue, ordering,
production records, dispatch records and invoice drafts, with per-customer
pricing computed by a rules engine rather than remembered. Phase 1 was signed
off in April 2026 as a usable foundation, running as a hosted preview behind
secure access, staged for client review.

Deeper accounting integration and full invoicing were deliberately scoped into
phase 2.

We drew that line where the system stops depending on someone else's system,
rather than where the work got hard. Order to dispatch sits entirely inside the
client's own four walls, so we control the rules, the data and the edge cases.
Posting finished invoices into an accounting package means living with a third
party's API, its authentication model and its opinions about what a valid
invoice looks like. Build that first and you are integrating against a process
you have not finished designing. Build it second and you are integrating a
shape you already know is right.

Deferring is not delivering less. It is being wrong earlier and more cheaply,
which is most of what good delivery actually is. The full write-up is in [the
trade portal case study](/work/manufacturer-trade-portal).

## Four questions to phase your own project

1. **Which single flow, if it worked properly, would change your week?** That
   is the spine of phase 1. Everything else is scenery until the spine holds
   weight.
2. **Which parts depend on someone else's system?** Accounting packages,
   couriers, payment providers, anything with an API you do not control. Push
   them right, unless the integration is the entire point of the project.
3. **What can you load with real data on day one?** That trade portal was
   seeded from the client's own price-list workbook, so it stood up loaded with
   around 74 customers, 888 products and 1,263 price rules rather than three
   tidy fake ones. Fake data hides exactly the problems real data finds.
4. **What are you keeping just in case?** Every brief has items nobody can
   describe an actual Monday morning for. Those are not phase 2. They are phase
   never, and saying so out loud is the cheapest decision you will make all
   project.

Answer those four and you have a scope. Answer none of them and you have a
wish-list, which is a different document that costs a lot more.

## What to do with this on your own project

Write down your phase 1 in one sentence, in the form "someone in the office can
do X from start to finish without leaving the system". If you cannot finish
that sentence, the scope is not ready, and no amount of quoting will make it
ready. If you can, you have something a developer can price honestly and you
can check when it arrives.

There is no sleight of hand in any of this. Phasing well is just refusing to
guess for six months at a time, then testing what you built against real data
before anyone's Monday depends on it.

If you would rather work through it with someone who ships this sort of thing,
that is what an [Automation Opportunity Audit](/services) is for: we map how
your business actually runs and hand you a ranked, costed plan for what to fix
first, from £450, with the fee credited against a Sprint (from £1,950) or a
Build (from £4,500) if you go on to do one. Fill in [the form](/contact) and
Waseem reads it himself, then emails you back. We promise a meeting within one
week, and a human makes every decision along the way.
]]></content:encoded>
</item>
<item>
<title>Manufacturing order processing: getting off phone-and-memory pricing</title>
<link>https://automancer.uk/field-notes/manufacturing-order-processing-phone-and-memory-pricing</link>
<guid>https://automancer.uk/field-notes/manufacturing-order-processing-phone-and-memory-pricing</guid>
<pubDate>Mon, 20 Jul 2026 00:00:00 GMT</pubDate>
<description>Trade pricing kept in someone's head is a single point of failure. What a B2B trade portal for a UK manufacturer actually needs, and in what order.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Ring most UK trade suppliers with an account and you get a person, not a
system. They know who you are, they know your pricing, and the order is on
its way before you have finished the sentence. That is genuinely good
service. It is also one head cold away from being no service at all.

## What actually goes wrong when the pricing lives in someone's head

Per-customer trade pricing is a relationship asset. A builder gets a better
rate because they have bought every month for years, and someone in the
office knows that. Nothing about the arrangement is written down anywhere a
computer could check it.

The failure modes are boring and predictable, which is exactly why they get
tolerated for years. The person who remembers is off, so an order sits until
Thursday or goes out at the wrong number. The account list grows past what
one memory can hold, and quotes start drifting. A price gets given wrong and
eats the margin on that job quietly, because nobody reconciles quoted price
against list price afterwards. Then that person retires, and a good chunk of
your commercial policy retires with them.

None of that is an argument for stripping the relationship out of the sale.
It is an argument for writing the relationship down, so the system knows what
the person knows and the person is freed up to do the part only a human can.

## What does a B2B trade portal for a manufacturer actually need?

A trade portal earns its keep when order, production, dispatch and invoicing
run as one flow rather than five disconnected tools. In practice that means:
account-specific pricing computed per customer, a catalogue those customers
can browse themselves, ordering and quick reordering, a staff-side order
queue, production records, dispatch records, and a draft invoice that falls
out of the end of the process instead of being typed up from scratch.

The word carrying the weight there is "one". Most manufacturers already have
every item on that list. They just have them in six places: an inbox, a
whiteboard, a price-list spreadsheet, an accounting package, a delivery book
and someone's memory. Every join between those six is a re-key, and a re-key
is where the number goes wrong.

## The multi-unit problem generic e-commerce doesn't solve

If you sell building products, you do not sell in units. You sell in feet,
metres, square feet, square metres and each, and the same product moves
between them depending on who is buying and what they are doing with it.

Off-the-shelf e-commerce platforms are built for a world where a product has
a price. Yours has a price per unit type, per customer, which is a different
shape entirely. Force it into a shopping-cart platform and you end up
maintaining a spreadsheet alongside the system that was supposed to replace
the spreadsheet.

There is a second thing generic platforms rarely handle well: what happens
when the sheet price moves. If a supplier puts up your raw material cost, you
need to reprice in bulk and have every account's specific arrangement follow
along, not hand-edit hundreds of rules and hope. Add cross-border orders into
Ireland and the gap between "an online shop" and "a trade system" is fairly
obvious.

## What we built for one manufacturer

For a UK plastics manufacturer and trade supplier, we replaced informal
order-taking with a full trade portal covering the whole order lifecycle.
Customer side: a public brochure site, secure passwordless login for trade
customers, and a portal showing their own account-specific pricing, the
catalogue, ordering and quick reorder. Staff side: a workspace for managing
customers, products and price rules, an order queue, production records,
dispatch records and invoice drafts.

At the centre sits a multi-unit pricing matrix covering feet, metres, square
feet, square metres or each, with bulk reprice, plus handling for cross-border
orders into Ireland. The demo was seeded from the client's own real price-list
workbook, so it stood up loaded with around 74 customers, 888 products and
1,263 price rules on day one rather than three tidy fake ones.

Phase 1 was signed off in April 2026 as a usable foundation: order to dispatch
working end to end, running as a hosted preview behind secure access, staged
for client review. Deeper accounting integration and full invoicing were
deliberately scoped into Phase 2, so the client got something real early and
we built the rest on proven ground.

Per-customer pricing is now computed rather than remembered. That is the whole
trick, and it is not much of a trick: it is a rules engine, written down
carefully, tested end to end. Not magic. Just very good engineering. You can
read the full write-up in [the trade portal case
study](/work/manufacturer-trade-portal).

## Where to start if this sounds like your business

You do not have to commission a portal to make progress this quarter. Start
with three questions, in this order.

1. **Where does your pricing actually live?** If the honest answer is "in
   Dave's head and a spreadsheet only he opens", that is your single point of
   failure, and it is a bigger commercial risk than any software decision you
   are weighing up.
2. **How many times does one order get typed in?** Count the re-keys between
   the enquiry landing and the invoice going out. Count them honestly,
   including the ones that feel too small to count. Each is a place a digit
   can slip.
3. **What is the smallest useful first phase?** Not the finished system. The
   smallest thing your team could genuinely use on a Monday morning and
   trust. If nobody can name it, the scope is not ready yet.

Those three answers will tell you more than any vendor demo will. If you would
rather work through them with someone who builds this sort of thing for a
living, an [Automation Opportunity Audit](/services) is exactly that: we map
how your business actually runs and hand you a ranked, costed plan for what to
fix first, from £450, with the fee credited against any project you go on to
do. No funnel, no discovery-call theatre. Just a straight look at where your
orders are leaking time.
]]></content:encoded>
</item>
<item>
<title>Five signs your business has a spreadsheet problem, not a software problem</title>
<link>https://automancer.uk/field-notes/five-signs-spreadsheet-problem</link>
<guid>https://automancer.uk/field-notes/five-signs-spreadsheet-problem</guid>
<pubDate>Mon, 13 Jul 2026 00:00:00 GMT</pubDate>
<description>Five signs a UK small business has outgrown its spreadsheets: disagreeing numbers, a single point of failure, weekly re-keying and a 'do not touch' tab.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Most businesses do not decide to run on spreadsheets. They arrive there one
tab at a time, because a spreadsheet is the fastest way to solve today's
problem, and today's problem always wins. That is fine, right up until the
spreadsheet stops being a tool you use and becomes a thing you maintain.
Here is how to tell which side of that line you are on.

## How do I know if my business is too reliant on spreadsheets?

You have a spreadsheet problem, not a software problem, when the spreadsheet
has stopped recording how the business runs and started dictating it. The
tell is friction: work now bends around the file's limits instead of the
file serving the work. The five signs below are the specific shapes that
friction takes. If two or more sound like a normal Tuesday in your business,
the spreadsheet is no longer saving you time. It is quietly charging rent.

## Sign 1: the same number lives in three places, and they disagree

Ask three people in your business for the same figure, your current
headcount, this month's revenue, how many orders are open, and see if you
get the same answer. In a lot of small businesses you do not, because that
number lives in a rota, an accounting package and a spreadsheet, and nobody
appointed one of them as the truth.

This is the reconciliation problem, and it is the most common hidden cost in
small-business operations. Nobody notices until the numbers are wrong in a
meeting, in front of someone who matters. The fix is not a better
spreadsheet. It is deciding which system is the source of truth and making
the others agree with it on purpose, not by hope.

## Sign 2: one person is the only one who knows how it works

There is a spreadsheet, and there is a person who understands the
spreadsheet, and the business runs on the overlap. When that person is on
holiday, a normal task becomes a research project. When they leave, a
working process leaves with them.

That is not a criticism of the person. They built something genuinely
useful. But a business should not have a single point of failure sitting in
one head and one file, because that is the one part of your operation you
cannot audit, back up, or hand over. Software that anyone on the team can
use turns private knowledge into a shared process. That is most of the value
right there, before you automate a single thing.

## Sign 3: there is a tab called "DO NOT TOUCH"

Every long-lived spreadsheet grows a tab like this. A hidden sheet full of
lookup tables and formulas that took an afternoon to get right and would
take a week to rebuild. A red cell nobody is allowed near. A macro someone
wrote in 2021 that still runs and nobody remembers why.

A "DO NOT TOUCH" tab is a confession. It means the spreadsheet is now doing
a job that needs the discipline of actual software, versioning, testing, a
record of what changed and who changed it, but has none of the safety rails
that come with it. The work has outgrown the tool. The warning label is the
spreadsheet telling you so.

## Sign 4: you re-key the same data into a second system every week

If a person on your team spends part of every week copying data out of one
place and typing it into another, that is not a workflow. It is a job for a
machine that has been given to a human. It is slow, it is boring, and it is
where errors breed, because a person re-keying the same fields for the
hundredth time is exactly when a digit slips.

The cost is easy to miss because it is spread thin. Ten minutes here, twenty
there, never big enough on any single day to fix. Add it up across a year
and it is often a meaningful slice of someone's salary spent moving data
that never needed a human to move it. This is usually the first thing worth
automating, not the biggest system, the most repeated re-key.

## Sign 5: you cannot get an accurate number, right now, for something that matters

Someone asks how the business is doing today. Not last quarter, once the
accounts are done. Today. And the honest answer is "give me a couple of days
to pull it together". Revenue, occupancy, hours logged, stock on hand, the
number that tells you whether this week is going well. If you cannot see it
without a manual assembly job, you are flying on last month's instruments.

A business should be able to answer its own most important question on any
ordinary day, not just at month-end. When it cannot, that is rarely because
the data does not exist. It is because the data is scattered across files
that were never built to give you a live view, only a snapshot someone has
to reassemble by hand each time.

## What to actually do about it

Notice that none of these five signs is "the spreadsheet is bad". Spreadsheets
are brilliant. They are the right tool for a genuinely surprising amount of
work, and swapping one out for software you do not need is its own expensive
mistake. The signs above are not "you failed at spreadsheets". They are the
spreadsheet honestly telling you it has been promoted past its job.

So do not start by buying software. Start by auditing:

1. **Map how the business actually runs**, tools, handoffs and re-keys
   included, not how the org chart says it runs.
2. **For each step, ask who does it, how often, and what it costs** in time or
   money when it goes wrong.
3. **Rank by frequency and pain, not by how interesting it is to fix.** The
   dull, daily, error-prone re-key beats the exciting rebuild almost every
   time.

That order matters, because the point is never to have the most software. It
is to stop paying, in time and mistakes, for work a machine should be doing.
Sometimes the answer really is a better spreadsheet. Sometimes it is one
small automation. Occasionally it is a proper custom system. You cannot know
which until you have looked, honestly, at where the friction actually is.

If you would rather not do that first pass alone, an [Automation Opportunity
Audit](/services) is exactly that working session done rigorously: we map how
your business runs and hand you a ranked, costed plan for what to fix first,
with the fee credited against any project you go on to do. You can also read
[how we work](/about), agents do the boring work, a human makes every
decision and takes every call, before you decide whether any of it is for
you. No funnel, no countdown, just a look at where your week is actually
going.
]]></content:encoded>
</item>
<item>
<title>CQC compliance evidence: how to stop scrambling before an inspection</title>
<link>https://automancer.uk/field-notes/cqc-compliance-evidence-stop-scrambling</link>
<guid>https://automancer.uk/field-notes/cqc-compliance-evidence-stop-scrambling</guid>
<pubDate>Mon, 06 Jul 2026 00:00:00 GMT</pubDate>
<description>How UK care providers stop scrambling before a CQC inspection: turn scattered training records and QA signals into one source of truth.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Every care provider knows the feeling. An inspection is coming, and
someone loses three days pulling training certificates out of four
systems, chasing refresher dates, and rebuilding a picture the business
should have been able to show at any moment. That scramble is not a sign
your care is poor. It is a sign your evidence lives in too many places.

## The real problem is where your evidence lives, not whether you have it

If you are scrambling before a CQC inspection, the fix is not more effort
the week before. It is a single source of truth you can point an inspector
at on any ordinary Tuesday. Most providers already do the caring well.
What they struggle to do is produce the evidence quickly, because it is
spread across an outsourced training provider, a rota spreadsheet, an
incident log, and one manager's memory of who is overdue on their
moving-and-handling refresher.

That is not a failing on your part. It is what happens when a sector this
heavily regulated gets served by tools that were each built to do one
slice of the job and none of them built to talk to the others.

## What a single source of truth for training actually looks like

To prepare training records for a CQC inspection without the last-minute
panic, you need one system that tracks three states for every member of
staff automatically: what is mandatory, what is due for a refresher, and
what is overdue. Not a spreadsheet someone re-reads and colour-codes by
hand the week before, but a live record that already knows the answer.

Most off-the-shelf learning platforms do not do this natively. They will
host courses and mark completions, then leave the compliance question, the
"who is out of date, right now, and on what" question, back on your plate.

We built exactly this layer on a real project for a ~600-person
supported-living care provider. We replaced outsourced training and manual,
spreadsheet-based refresher-tracking with a self-hosted learning management
system, plus a custom compliance layer to track mandatory, refresher and
overdue training the off-the-shelf tool could not handle on its own. It was
seeded across all three of the provider's branches with courses loaded.
The point of that layer is simple: it turns scattered inspection evidence
into one place you can actually point an inspector at.

## What a QA oversight dashboard surfaces that a manual review can't

A quality dashboard earns its keep between inspections, not just before
them. Done properly, it stops being a report you assemble and becomes a
view that is already assembled, showing you the exceptions before a
regulator does.

On the same build, the QA and management oversight dashboard is live. It
pulls care-quality signals from multiple systems into one view: KPI cards,
branch comparisons, a support-worker priority watchlist, a repeat-concern
watchlist for service users, medication review, and a filterable review
queue. Instead of hunting through separate systems for the thing that
needs attention, a manager opens one screen and sees it. That is the
difference between evidence you have to go and find and evidence that
comes to you.

## The honest bit: "staged for go-live" is not the same as "live"

Here is the part most vendors skip. Not all of this happens overnight, and
pretending it does would be its own kind of dishonesty.

On that provider's build, the QA dashboard is genuinely live and in daily
use. The learning management system and its compliance layer are seeded
across all three branches and staged for go-live, which is a specific
thing, not a softer word for "done". It means built, courses loaded, and
tested on staging, waiting on the client's sign-off before it touches real
staff records. Care records are not a place to move fast for its own sake.
Every lane of this work was scoped, built on staging, reconciled against
the client's real exports, and board-gated before it went anywhere near
live data.

There is no filing cabinet that quietly organises itself the night before
an inspection. There is just one system, kept current on purpose, so the
answer is already there when someone asks.

## What I'd actually do about this

If inspection prep is a recurring fire drill in your business, work in this
order:

1. **Put training compliance in one place first.** Mandatory, refresher and
   overdue, tracked automatically. This is the evidence an inspector asks
   for most predictably, so it is the highest-value thing to stop tracking
   by hand.
2. **Add the oversight view second.** Once the underlying records are
   trustworthy, a dashboard that surfaces exceptions is mostly plumbing,
   not a separate project.
3. **Insist on honest delivery status.** "Live", "staged for go-live" and
   "in build" mean different things. A supplier who blurs them before an
   inspection is not one you want near your care records.

If you cannot tell where your own evidence gaps are, that is what an
[Automation Opportunity Audit](/services) is for: a working session that
maps how your business actually runs and gives you a ranked, costed plan
for what to fix first. You can see the fuller care build behind this post
on our [care provider transformation](/work/care-provider-transformation)
write-up. No obligation to do any of it with us, and the audit fee comes
off if you do.
]]></content:encoded>
</item>
<item>
<title>Automation for care providers: where to start</title>
<link>https://automancer.uk/field-notes/automation-for-care-providers-where-to-start</link>
<guid>https://automancer.uk/field-notes/automation-for-care-providers-where-to-start</guid>
<pubDate>Sat, 04 Jul 2026 00:00:00 GMT</pubDate>
<description>A plain-English order of operations for automating a UK supported-living or domiciliary care business, based on real delivered work: canonical records first, then scheduling, then QA.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Supported-living and domiciliary care runs on paperwork most other sectors
don't have to think about: rosters, supervisions, medication records,
training compliance, incident logs, mileage claims, timesheets. If you're
running a CQC-regulated care business on spreadsheets and a patchwork of
outsourced platforms that don't talk to each other, you're not doing it
wrong. You're doing what almost every provider your size does. The
question isn't whether to automate. It's what to automate first, and in
what order, without putting real care data at risk while you do it.

## Why care providers can't just buy off-the-shelf software

Most business software assumes clean, stable data: one customer record,
one address, one relationship. Care providers don't have that luxury. A
service user has a care plan, a funding body, a next of kin, incident
history and a medication schedule that all need to line up. A support
worker has qualifications, DBS checks, supervision dates and shift
availability that all need to line up too. Generic CRM or rostering tools
handle a slice of that and leave the rest in spreadsheets, which is how
most providers end up with the same person's details spelled three
different ways across four systems.

That's not a software failure. It's what happens when a sector with this
much regulatory complexity gets served by tools built for simpler
businesses.

## Start with canonical records, not the flashy dashboard

If you're planning where to automate first, resist the pull toward the
most visible thing (a nice-looking dashboard) and start with the least
visible thing: one clean, canonical record per person. Every downstream
automation, from scheduling to compliance tracking to QA reporting, is
only as trustworthy as the record it's built on.

We proved this out on a real build: a single roster import for a
~600-person supported-living provider turned messy client CSVs into
**294 carers and 293 service users** as clean, canonical, auditable
records. Identity matching (comparison logic that decides "same person"
across systems) **auto-resolved 274 of 418** review candidates, so a human
only had to look at the ones that were genuinely ambiguous. Get this layer
right and everything you build afterward gets easier. Skip it and you're
automating on top of duplicate data, which just makes the mess move
faster.

## Then scheduling, because it compounds

Once you have canonical records, scheduling is usually the next highest-
value target, because it's the thing that repeats constantly and fails
quietly. Supervisions and spot checks are a good example: they're a
regulatory requirement, they happen on a cycle, and tracking that cycle by
hand across a growing workforce is exactly the kind of job a machine does
better than a person with a full diary. On the same build, **588
supervision and spot-check schedules were created automatically** once the
canonical records existed underneath them.

## QA and compliance evidence come last, and they come easier than you'd think

Once records and scheduling are automated, a QA or compliance-evidence
layer stops being a separate project and becomes mostly plumbing: pulling
signals that already exist into one place a manager or an inspector can
actually look at, instead of hunting through separate systems for
exceptions. Do this step first, before the record and scheduling layers
are solid, and you're just building a nicer window onto the same mess.

## A three-question checklist before you automate anything in a regulated care business

1. **Is this a canonical record, or a report built on top of one?**
   Automate records first. Reports second.
2. **What happens to this data if the automation gets it wrong?** If the
   answer touches medication, safeguarding or a regulator's evidence
   trail, it needs to be staged, tested against real exports, and signed
   off by a human before it goes anywhere near live service-user data.
   Never move fast for its own sake here.
3. **Can you point to a verified backup and a tested restore, not just a
   backup policy on paper?** Infrastructure discipline matters more in
   care than almost anywhere else. On our own build, the documented
   production infrastructure audit came back with zero failures and zero
   warnings across every layer, including a genuinely restored backup, not
   a hopeful one.

## It's not magic. It's the right order of operations

None of this is a secret trick. It's the same discipline you'd want from
any engineer working near care records: get the foundation right, stage
everything, reconcile against real data, and let a human sign off before
anything touches production. That's how we approached the whole
transformation for [a ~600-person supported-living care provider](/work/care-provider-transformation),
delivered as roughly eighteen governed workstreams rather than one risky
big-bang rebuild.

If you're looking at your own care business and can't tell where to start,
that's exactly what an [Automation Opportunity Audit](/services) is for:
a working session that maps how your business actually runs, and a ranked,
costed plan for what to automate first. No obligation to do any of it with
us, and the fee comes off if you do.
]]></content:encoded>
</item>
<item>
<title>What does an AI agent actually cost? A 2026 UK price breakdown</title>
<link>https://automancer.uk/field-notes/what-does-an-ai-agent-actually-cost</link>
<guid>https://automancer.uk/field-notes/what-does-an-ai-agent-actually-cost</guid>
<pubDate>Sat, 04 Jul 2026 00:00:00 GMT</pubDate>
<description>Real published UK prices for AI agent and automation projects: audits from £450, not the five- or six-figure guess most vendors make you wait for.</description>
<content:encoded xmlns:content="http://purl.org/rss/1.0/modules/content/"><![CDATA[Someone pitches you an "AI agent" for your business. You ask how much it
costs. You get "it depends", a discovery call, and a number that only
appears after you've sat through a sales deck. Here's the honest version
of "it depends", with real prices attached, not a funnel.

## The short answer

For a UK small business, a genuinely useful automation or AI agent project
typically starts in the low thousands, not the tens of thousands. The
range depends entirely on scope: a single automated workflow can be live
in around two weeks from roughly £1,950. A proper custom system or AI
agent built to last starts from £4,500. If you don't yet know what's worth
automating, an Automation Opportunity Audit starts the whole process for
£450, and that fee comes straight off if you go on to do the work with us.
Those are our own published prices, not industry averages, but they're a
real, current UK data point for what this actually costs when a vendor
tells you the truth up front.

## Why "it depends" isn't a dodge, but it's also not an excuse

The honest reason cost varies is that "AI agent" covers wildly different
amounts of engineering. A script that reads an inbox and drafts a reply
for a human to approve is a different job from a system that ingests
messy client data, matches identities across records, and writes back into
three other platforms. Vendors who say "it depends" and then refuse to
give you *any* number until you've sat through a call aren't protecting
you from a bad estimate. They're protecting their pricing from comparison.

## What actually moves the price

- **How much human review stays in the loop.** More judgement calls kept
  with a person costs more to build (proper approval flows, audit trails)
  but usually costs less in risk. We build this in by default, not as an
  upsell: a human makes every decision and takes every call on anything
  that matters.
- **How many systems it has to talk to.** One clean workflow between two
  tools is a Sprint-sized job. A system that has to reconcile data across
  four platforms and keep them in agreement is a Build.
- **Data quality going in.** Clean source data is cheap to automate on top
  of. Messy, duplicated, inconsistent data (which is most small
  businesses, honestly) needs a records layer built first, which is real
  work, not padding.
- **What "properly built" actually includes.** Audited, monitored, backed
  up and tested infrastructure costs more up front than a demo that only
  has to survive one meeting. It's also the difference between something
  that's still running in six months and something that quietly breaks the
  first busy Monday.

## What that looks like against a real number

We built a self-service AI product for a diversity & inclusion consultancy
that replaced a **£300–400 consultant engagement** with a **£10–80
self-service task, completed in minutes instead of hours**. That's not a
cost estimate for a generic AI agent. It's the real economics of one
[shipped product](/work/debiaser-ai-product), included here because it's a
useful sanity check: a well-built AI product doesn't just move a task from
a person to a machine, it can fundamentally change what the task costs the
customer, because the delivery model changed, not just the labour.

## A quick way to sanity-check any AI agent quote you're given

Ask three questions before you sign anything:

1. **Can you show me this running in production somewhere, today, not in
   a slide deck?** If the answer is no, you're paying for a prototype, not
   an agent.
2. **What happens when it gets something wrong, and who signs off before
   it acts?** If there's no human in the loop for anything that touches
   money, customers, or compliance, that's a red flag, not a feature.
3. **Is the quote a real number, or a range that only becomes real after a
   sales call?** A vendor who can't give you a ballpark before a meeting
   usually has a reason not to.

## Our own answer, published, not pitched

- **Automation Opportunity Audit:** from £450. Fee credited against any
  project you go on to do.
- **Workflow Sprint:** from £1,950. 1–3 automations live in around two
  weeks.
- **System / Agent Build:** from £4,500. A proper custom system or AI
  agent, built to last.
- **AI Ops Partner:** from £495/month, cancel anytime. We keep it running
  and keep automating the next thing.

Full detail on what's included at each level is on our [services and
pricing page](/services). If you're not sure which one fits, start with
the Audit. That's exactly what it's designed to answer.
]]></content:encoded>
</item>
</channel>
</rss>