Skip to content

AI and workflow automation built around the systems you already run

Most of the automation work we do is unglamorous, and that is rather the point. A quote someone types out by hand over and over. A day of driver routes worked out on paper every morning. An enquiry that arrives at nine in the evening and sits in an inbox until somebody opens it the next day. The job is to find the specific repeated task, write software that performs it against your real data, and put it where the business already works rather than in another tool nobody remembers to open.

For EFR Skips and Onyx Recycling we built a WhatsApp Business integration that quotes skip hire from the same pricing engine the office system uses. That detail matters more than the chat window does. The bot is not reading a copy of the price list or a summary of the website, it calls the same server-authoritative quote engine as everything else, so the public sites, the office system and WhatsApp cannot drift apart on price. For the same group we built an automated dispatch planner that assembles each driver's day from live drive-time data while respecting the physical reality of skip work: only one full skip on a lorry at a time, so every collection forces a tip, separate sites for metal and general waste, and an empty body that can only serve the next delivery if the size matches.

We should be precise about the word AI, because plenty of agencies are not. What we have built, and what we can show you, is integration and automation engineering: software that carries out a defined task against live business data, wired into the systems that already hold the truth. Where a language model earns a place in that, it sits in front of a system of record rather than in place of one, and it does not get to invent the price. We have not trained machine-learning models for clients and we do not claim to. If your problem needs a model trained on your own data, we will say so on the first call and point you towards people who do that for a living.

What's included

  • A written process map before any code is written, covering the real steps, who performs each one today, the exceptions that break the happy path, and an honest note on which parts are not worth automating.
  • Chatbot and WhatsApp Business builds that answer from your live system rather than a scraped copy of your website, so a price given in a chat is the same price the office would give.
  • One server-authoritative calculation for anything involving money, shared by every channel, so the website, the internal system and the automation cannot disagree with each other.
  • Scheduling and dispatch automation of the kind built for EFR, where a driver's day is assembled from live drive-time data and the real constraints of the job instead of by hand each morning.
  • Customer self-service that takes work off the phone, as on the EFR order portal, where a private per-order link lets a customer extend a hire, book a collection, swap to a different skip size or settle a balance without ringing the office.
  • Enquiry and registration pipelines with honeypot filtering, server-side validation and email-keyed deduplication, so a second submission updates the existing contact rather than creating a duplicate.
  • Failure handling designed in rather than bolted on: on the Qube funnel the registration is written to the database before the emails are attempted, so a dead mail server costs a notification instead of a lead.
  • An admin view and an audit trail. For Qube that is a private CRM behind Google sign-in with a status pipeline, notes, search, audit logging and CSV export, so you can see what the automation did and work the results yourself.

How it runs

  1. 1

    Mapping the process

    We start by watching the work happen. That means time with the people who actually do the task, not only the owner's description of it, because the exceptions are where automation succeeds or fails and the exceptions live with the staff. We write down the steps, the edge cases, the systems involved and where the data really sits. You get a fixed scope and a fixed price out of that, and sometimes you get a recommendation not to automate a particular step at all. What you will not get is a predicted saving, because we cannot honestly forecast one.

  2. 2

    One workflow, built end to end

    We build the narrowest version that does a whole job rather than a broad system that half-does five. One quote path. One registration form. One dispatch run. It runs against your real systems early, because automation that only works on sample data is not evidence of anything. Where money is involved the calculation lives in one place on the server and every channel calls it, which is how a chat window and an office screen are kept from quoting different numbers.

  3. 3

    Running alongside the humans

    New automation runs in parallel with the manual process before it replaces it. Somebody keeps doing the job the old way for a while and the two sets of output get compared. That is how you find the case nobody mentioned in the mapping session: the address that sits awkwardly between two pricing zones, the customer who wants a different skip size halfway through a hire, the question the bot should never have tried to answer. Only once the outputs agree does anything get switched over.

  4. 4

    Handover and upkeep

    You get an admin view showing what ran, on what input, and with what result, plus documentation written for whoever picks it up after us. Automation rots when the underlying process changes and nobody tells the software, so we stay on for those changes: a new price band, a new postcode zone, a new question the bot starts getting every week. We build each part so it can be switched off on its own without taking the rest down with it.

This is a good fit if

  • Businesses where the same administrative task repeats every day and the rules behind it are consistent enough to write down, even if nobody has written them down yet.
  • Companies already running a system of record, whether that is a booking system, an accounting package or a spreadsheet everyone trusts, that automation can read from and write back to.
  • Owners losing enquiries outside office hours who need an instant answer, but cannot risk a wrong price or a promise the business is unable to keep.
  • Operations and admin functions spending their week moving the same information between two systems that were never built to talk to each other.

Probably not, if

  • Anyone who needs a machine-learning model trained on their own data: demand forecasting, image recognition, a model fine-tuned on your document archive. That is a different discipline from the integration and automation work we have actually delivered, and we would rather tell you now than learn it on your budget.
  • Businesses where the process itself is not agreed. If three people do the same job three different ways and nobody can say which one is correct, automation only makes the disagreement faster and harder to unpick. That needs sorting first, and it may not need us at all.
  • Work where a wrong answer is unacceptable and no human can sit in the loop, such as regulated advice, clinical or legal determinations, or anything where a confident-sounding mistake does real damage. A language model is the wrong tool for that and we will say so rather than sell you one.

Want a price for this?

Tell us what you need and we'll come back with a fixed scope and a fixed price, usually within 24 hours.