Skip to content
ChurnTech

Managed automation

Bring us the problem.We'll run the solution.

Done for you, end to end. We research the problem, design the workflow, build and integrate it, test it on your data, and then operate it. You don't get a tool recommendation, or a set of subscriptions to configure yourself.

Talk about an automation projectHow an engagement works

01Who it's for

Three situations we recognise.

  1. 01

    Someone does the same thing every week

    Copying data between tabs, chasing approvals, publishing the same content to three places. It works, but it depends on one person remembering.

  2. 02

    A spreadsheet or script nobody owns

    It started as a quick fix and now something important runs on it. Nobody is sure what happens if it breaks, or who would notice.

  3. 03

    Tools you already pay for don't talk to each other

    The CRM, the billing system, the CMS and the inbox each hold part of the picture. You want them connected and watched, not wired by hand.

02How an engagement works

Five stages. A written plan before any build.

You see what we intend to do, what it will cost to run and what could go wrong before we start building.
Fig. 1 — A typical engagementTimings are indicative and depend on scope.

  1. Week 1Together

    Diagnose

    We map the process, data and systems with you.

  2. Week 1–2ChurnTech

    Design

    A written plan: workflow, tools, costs, risks.

  3. Weeks 2–6ChurnTech

    Build & integrate

    Automations, integrations and any custom code.

  4. Before launchTogether

    Test on real data

    Edge cases, failure paths, approvals.

  5. OngoingChurnTech

    Operate

    Monitoring, fixes, changes, monthly report.

Changes and improvements continue under the operating agreement

What you receive at each stage

  1. 01Diagnose

    A process map

    Each step as it works today: who does it, which systems and data it touches, how often, and where it goes wrong.

  2. 02Design

    A written plan

    The proposed workflow, the tools it uses and what each costs to run, the risks, and what we don't yet know. Nothing is built until you have read and approved it.

  3. 03Build & integrate

    A working system

    Running somewhere you can see it, connected to your tools, with the workflows, code and configuration kept in accounts you control wherever the tools allow.

  4. 04Test on real data

    A test report

    What we tried, including the odd inputs and the failure paths, what broke, and what we changed. Approval steps are tested with the people who will use them.

  5. 05Operate

    A runbook and a monthly operating report

    How the system works, what its alerts mean and what to do about them, written for someone who didn't build it. Then, each month, what ran, what failed and what we changed.

What we need from you

  • Access

    To the systems the process touches, through accounts you control and with the narrowest permissions that work. We start read-only where we can.

  • A decision-maker

    One person who can approve the written plan, answer questions about how the business actually works, and say yes or no to changes.

  • Sample data

    Real, representative examples, including the awkward ones. Redacted or minimised data is fine for most of the build.

03What you can commission

Six kinds of work, each with its proof.

Every one is something we have already built for ourselves. The proof line says where.

  1. 01

    Content operations

    Research, drafting, automated quality review and human-approved publishing into your CMS, with optional social scheduling.

    What you get

    • A topic and research stage that feeds drafts, not blank pages
    • Automated quality and SEO checks before a person sees a draft
    • An approval step that nothing publishes without
    • Social drafts and scheduling from the approved piece

    Typical tools

    • n8n
    • Language-model APIs
    • Your CMS
    • Buffer

    Internal proof

    A nine-workflow n8n pipeline we built for QR Rapid's blog.

    Case study: the AI content pipeline

  2. 02

    Workflow automation & integrations

    Connect the tools you already pay for — forms, CRM, billing, CMS, messaging — with monitored workflows instead of copy-paste.

    What you get

    • Workflows that retry, log what they did and alert when they can't continue
    • Integrations through APIs and webhooks, with credentials kept out of the workflow itself
    • Documentation of every connection and what happens when one fails

    Typical tools

    • n8n
    • Webhooks
    • REST APIs
    • The tools you already use

    Internal proof

    Stripe billing webhooks plus Notion, Buffer and object-storage integrations in QR Rapid.

    QR Rapid platform

  3. 03

    Data pipelines & reporting

    Scheduled imports with a quality report on every run, and reporting with written metric definitions — not dashboards you have to babysit.

    What you get

    • Imports from files and APIs that run on a schedule and report what they rejected
    • Background workers for large or slow jobs, so nothing waits on a web request
    • Written definitions for every number in a report, so two people read it the same way

    Typical tools

    • Queue workers
    • Scheduled jobs
    • CSV and XLSX
    • Your database or warehouse

    Internal proof

    Bulk creation from CSV and XLSX files, run by Redis and BullMQ queue workers.

    QR Rapid platform

  4. 04

    Managed infrastructure & monitoring

    Deployment, backups with tested restores, uptime and anomaly alerts — run by us, documented for you.

    What you get

    • Automated deployments, so a release is a routine event
    • Scheduled backups, stored off-site, with restores actually tested
    • Uptime checks that run independently of what they watch
    • Alerts on the things that cost money when they drift

    Typical tools

    • CI deploys
    • Object storage
    • Uptime monitoring
    • Alerting

    Internal proof

    How we run QR Rapid: database dumps every 6 hours, encrypted off-site snapshots, weekly restore tests, independent uptime monitoring, and a billing anomaly monitor with alerts.

    QR Rapid platform

  5. 05

    AI features & agent integrations

    Language-model features with guardrails: the model proposes, a person confirms, the system validates.

    What you get

    • A model that returns structured drafts rather than free text
    • A confirmation step, so a person approves before anything changes
    • Validation of every proposal against your own rules
    • Secure access for AI agents to your product through an MCP server

    Typical tools

    • Language-model APIs
    • Schema validation
    • MCP
    • OAuth 2.1

    Internal proof

    Rapid AI, where a model proposes and the user confirms, and an OAuth 2.1-secured MCP server we have built for QR Rapid.

    QR Rapid

  6. 06

    Custom software & internal tools

    When a workflow tool isn't enough: services, back-offices and APIs, built to be operated.

    What you get

    • Small services, admin back-offices and APIs scoped to the job
    • Background workers and a deployment pipeline from the first release
    • Source code and documentation handed to you, not kept behind a retainer

    Typical tools

    • Web apps and APIs
    • Queue workers
    • Small separate services

    Internal proof

    The engineering behind QR Rapid: a web app, a separate scan service, queue workers and an asset service.

    QR Rapid platform

04Example architecture

What one of these systems looks like.

A content pipeline with a person at the one point where judgement matters, and automation everywhere else.

  1. 01

    Research

    Topics and sources gathered into a brief

  2. 02

    Draft

    A language model writes against the brief

  3. 03

    Automated review

    Quality and SEO checks; weak drafts go back

  4. 04Person

    Human approval

    A person reads and approves. Nothing publishes without it

  5. 05

    Publish

    The approved piece goes live in the CMS

  6. 06

    Social drafts

    Posts drafted from the published article

  7. 07

    Scheduling

    Queued for release through Buffer

Drafts that fail the automated review go back for another pass before a person sees them

Built for QR Rapid's own blog

Nine n8n workflows cover these stages. It is an internal build, not client work, and we aren't claiming more than that. What it shows is the design: a language model drafts, automated checks catch the obvious problems, a person approves, and only then does anything go live.

For a client the shape stays; the CMS, the review rules and the channels change.

05Operating

Operating, not handing over.

A system that ran fine on launch day still needs someone watching it in month six. That is part of the work, not an extra.

  • 01

    Monitoring

    Every workflow reports whether it ran and whether it finished. We watch for the quiet failures too: a job that stopped running is as bad as one that failed.

  • 02

    Alerts

    Alerts go to people, with enough context to act on. We tune out the noise so the ones that remain mean something.

  • 03

    Fixes

    When an upstream API changes or a credential expires, we repair it and tell you what happened.

  • 04

    Changes

    Your process will move. Changes and improvements are made under the operating agreement, in the same documented way as the original build.

  • 05

    A monthly report

    What ran, what failed, what we changed and what we'd suggest next. In plain language, with the running costs included.

  • 06

    Documentation you keep

    The runbook and the workflow documentation are yours. You can take the system in-house, or to someone else, at any time.

Nothing is locked in. You can take the system in-house at any time, with the documentation to run it.

Honest note

New as a client service — built on systems we run ourselves.

We haven't yet delivered paid automation projects for clients, and we won't imply otherwise. What we have is a set of systems we built and operate for our own products. We'll tell you which parts of your project are new ground, and plan for them in the written design.

06Questions

Questions you're likely to have.

Do we need to buy tools?

Often you already own most of what's needed. The written plan lists every tool in the design and what each costs to run, before anything is built. Subscriptions sit in your name, and where a tool fits we prefer ones you can run yourself or move away from.

Who owns the code and the workflows?

You do. The workflows, code, configuration and documentation we deliver are yours, and the accounts they run in are yours wherever the tools allow. If we reuse something from our own systems, the plan names it, and the agreement states the terms before work starts.

What if we stop working with you?

You keep a working system and the documentation to run it. We hand over access, remove our own, and walk your team or another supplier through the runbook. There is no lock-in because the system lives in your accounts.

How do you handle our data?

We ask only for the data a stage needs, and use redacted or sample data for most of the build. Access is through accounts you control, with narrow permissions that we hand back at the end. If personal data is involved, or a language model will see any of your data, the plan says so and we agree how it's handled before we build.

Can you work with our existing systems?

That is usually the job. The diagnosis starts with what you already run. Most business tools expose an API, a webhook or an export we can work with. If one of yours doesn't, we tell you at the design stage, not halfway through the build.

Start here

Tell us the problem.

Describe the process as it is today and what a good outcome looks like. We'll say plainly whether we're the right people for it.

Talk about an automation project[email protected]