AI-first engineer and consultant, based in the UK

Practical AI, wired to your real data.

I’m Paul Blower. I build chatbots, support and store automation, document assistants and agents that work from your real orders, tickets and documents. They handle the routine and hand the rest to your team, with the context attached.

Email Paul

contact@paulblower.co.uk

  • AI tools in the loop every day: Cursor and current coding agents
  • I still review the code
  • The work has to ship
How a request is routed Requests arrive by web chat, email or Slack and go to an AI agent. The agent looks things up in your order system, documents or helpdesk, runs its checks, then either sends the answer or hands the case to your team with the context attached. Web chat Email Slack AI agent model + your rules Orders Docs Helpdesk checks Answered Your team
  1. web chat“Where’s my order? It’s #4471.”
  2. ordersshipped Tuesday, arriving Thursday
  3. checksroutine question, within limits
  4. answeredreply sent with the tracking link
  1. email“Lamp arrived broken. Refund please, £180.”
  2. ordersdelivered two days ago, paid £180
  3. helpdeskticket opened, photos attached
  4. checksover the £100 auto-refund limit
  5. your teamhanded over with the full history
  1. slack“What’s the notice period for contractors?”
  2. docsContractor Policy, section 4.2
  3. checksanswer backed by a source
  4. answered“30 days”, with the clause quoted
Fig. 1. Three everyday requests and where each one goes. The examples are illustrative.

What I build

Six practical jobs. Each starts with a problem you already have and ends with one working outcome, connected to the systems you already use.

  • Chatbot integrations

    Your chat widget can’t see orders, accounts or policies, so it guesses or sends people to email.

    I connect it to your store, helpdesk and CRM. It answers from real records, logs each conversation as a ticket and hands hard cases to your team with the context attached.

    Connects to Zendesk, Intercom, Gorgias, WhatsApp Business or your own API

  • Support automation

    Your team spends the day on the same dozen questions while the difficult tickets wait.

    First-line replies across chat and email for the repeat questions, written rules for what escalates, and a regular review of what it got wrong so it keeps improving.

    Connects to your helpdesk, shared inbox, help centre and order data

  • Store automation

    Order lookups, returns, product questions and stuck orders eat the hours you should be spending on the business.

    Catalogue-aware answers and order lookup for customers, product copy drafted for your approval, and alerts on stuck or failed orders before customers start chasing.

    Connects to Shopify or your platform, courier tracking, returns and stock

  • Knowledge assistants

    The answer is in a policy, contract or wiki page somewhere, and finding it takes twenty minutes and a colleague.

    An assistant that answers staff questions from your own documents, quotes the passage it used and says plainly when the documents don’t cover it.

    Connects to Google Drive, SharePoint, Notion, PDFs and internal wikis

  • Agents with a human handoff

    Routine jobs like refunds, address changes or lead triage still need someone clicking through four systems.

    An agent that reads the request, uses your systems to finish the routine cases and passes anything unusual or over a set limit to a person. Every action is logged.

    Connects to order and payment APIs, your CRM, Slack and an approval queue

  • Workflow automation

    Data moves between inboxes, forms, spreadsheets and your CRM by copy and paste, and mistakes surface weeks later.

    Automations that turn emails, documents and form submissions into clean records in the right system, keep tools in sync and tell someone when a step fails.

    Connects to n8n or plain code, Google Sheets, Airtable, HubSpot, Postgres

Fast with AI. Careful with what ships.

AI tools make one engineer quick. They don’t get the final say.

  • AI in the loop, every day

    I build with Cursor and current coding agents. They draft quickly, so you see working software sooner.

  • I still review the code

    Agents write first drafts. Nothing ships until I’ve read it, tested it against real cases and understood it well enough to support it.

  • Real data, early

    We test on your actual tickets, orders or documents from the start, so the awkward cases show up while they’re cheap to fix.

  • Guardrails in the first version

    Escalation rules, a log of every action, spending limits on model usage and an off switch. Not a phase two.

  • Yours to keep

    Your repository, your accounts, your API keys, and notes your team can follow without me.

refunds.ts agent’s draft after review
  const order = await orders.get(req.orderId);
Removed: - if (order.total < 500) {
Removed: -   return refund(order);
Removed: - }
Added: + const limit = policy.autoRefundLimit;
Added: + if (order.total <= limit && !order.flagged) {
Added: +   return refund(order);
Added: + }
Added: + return handOff(req, { attach: order });

Review note

The limit comes from the refund policy, not a number buried in code. Flagged orders and anything over the limit go to a person, with the order attached.

Example: an agent’s first draft, and what changed in review.

How an engagement works

One focused outcome at a time, with the scope and a fixed price agreed before any build starts.

  1. You email me the problem

    A few lines is enough: what’s slow or costly, which systems are involved and what good would look like. You’ll get a reply from me, usually with questions.

  2. I scope it on real data

    Before quoting, I look at real examples: past tickets, orders, documents and the systems involved. You get a short written scope covering what it will do, what it won’t, how we’ll measure it and a fixed price.

  3. I build it in your stack

    In your repository and accounts, or mine with a full handover. You see it working on real data early, and we adjust while changes are cheap.

  4. We test it, then go live

    It runs against real past conversations or questions, including the awkward ones, before a customer sees it. Escalation, logging and cost limits are on from day one.

  5. I stay on after launch

    I watch the logs, fix what real users find and hand over documentation. Ongoing support is there if you want it, never a condition.

What I won’t sell you

Plenty of AI work looks good in a meeting and never reaches a customer. I don’t sell any of it.

  • Won’t sell: A strategy deck with no code behind it

    Instead: A working first version you can try on your own data

  • Won’t sell: A demo that isn’t wired to your real data

    Instead: Software connected to your real systems from the first build

  • Won’t sell: A bot that only handles the questions it was rehearsed on

    Instead: Testing on real past conversations, awkward ones included

  • Won’t sell: An agent with no logs, no limits and no off switch

    Instead: Every action logged, spending capped and a clear route to a person

  • Won’t sell: AI where a simple rule would do

    Instead: A straight answer, even if it makes the job smaller

Questions

Anything else, ask in your email.

Do I need to be technical to work with you?

No. You need to know the problem and who deals with it today. I handle the models, APIs and hosting, and explain the trade-offs in plain English.

Which AI models do you use?

Whichever fits the job, your data rules and your budget. The choice goes in the written scope with an estimate of the monthly running cost, so there are no surprises later.

Who owns the code and the data?

You do. The code lives in your repository, runs in your accounts and uses your API keys. If we stop working together, everything keeps running.

What does it cost?

A fixed price for a scoped outcome, agreed before any build starts. Focused jobs cost less than broad ones, which is one reason I push for a focused first version.

What if AI isn’t the right answer?

Then I’ll say so. Sometimes a better help page, a form or a simple rule solves it for less, and you should do that instead.

Can you work alongside our developers?

Yes. I can build in your repository alongside your team and follow your review process, or deliver a finished system with documentation and a proper handover.

Tell me what’s slowing your team down.

A few lines is plenty. You’ll get a reply from me, not a sales team, with questions or an honest “not a fit”.

contact@paulblower.co.uk
Email Paul

Useful to include

  • What’s slow, costly or error-prone today
  • Which systems are involved
  • What good would look like