What we automate for ourselves, and what we learned
The automations we run inside our own company, what each replaced, what went wrong along the way, and the lessons we now apply to every client project.
The short answer
We run our own company on the automations we recommend, which is the only honest basis for recommending them. Our intake is automated from the first enquiry to a structured record and a scheduled call. Monitoring across every client site alerts the right person with the likely cause. Monthly client reports assemble themselves and arrive as drafts with a narrative to edit. Deployment checks enforce our own quality rules on every change, including the content rules for this knowledge base. Parts of our support flow classify and draft. Over the years some automations stuck and some were removed, and the pattern is consistent: what stuck was small, triggered by a real event, and replaced something a person kept forgetting; what we removed was clever, noisy or solved a problem we did not have. Every automation now has an owner, a log and a switch, because the ones without them caused the only real incidents we have had. AI earned its place in drafting and classifying, never in deciding, and the review step is where the quality came from.
What we run and what it replaced
| Automation | What it replaced | What it does now | Lesson |
|---|---|---|---|
| Intake | Enquiries answered when someone saw them; details re-asked | Acknowledges, qualifies, creates the record, proposes a call slot, notifies the owner | Speed of first response matters more than polish |
| Monitoring and alerting | Discovering outages from clients | Checks uptime, certificates, domains, forms; alerts by severity to the person on duty with a likely cause | The interrupt budget is real; we halved alerts and missed nothing |
| Client reporting | A day per client per month | Numbers assembled on schedule; AI drafts the narrative; the lead edits | The edit is the report; the draft is the time saving |
| Checks before delivery | Reminders about rules | A fixed set that runs before every delivery: schema validation, reference checks, style and link checks. The schema is the one that actually stops the build | Rules in the pipeline are followed; rules in a document are not |
| Content quality rules | Style guide nobody reread | The schema blocks the build on field lengths, required fields and unknown fields. Alongside it a scanner reports forbidden words and link targets, as a step rather than a gate | This knowledge base is built under the schema and those checks |
| Support classification | Reading every message to route it | Classifies type and urgency; drafts routine replies for review | Classification is reliable; deciding is not delegated |
| Access reviews | Remembering who has what | Quarterly report of every account and member; leavers flagged | The register is only true if generated |
| Invoice preparation | Assembled from memory | Drafted from logged work and retainers; reviewed | Finance trusts what it can trace |
What went wrong, and what changed
- Over-alerting: every event posted to one channel; the alert that mattered scrolled past. Now: severity routing, digests for the informational, and a quarterly review that removes alerts nobody acted on.
- A clever content flow: generated drafts from topic lists, nearly published. Removed. Now: AI drafts only from a human brief and never publishes; the quality gates block anything that reads generic.
- An ownerless automation: a sync that failed silently for weeks. Now: owner, log and switch for everything, and monitoring of the automations themselves.
- Too much too soon: a workflow with twelve steps that nobody understood when it broke. Now: small automations, each doing one thing, composed rather than combined.
- Skipping the measurement: automations kept because they felt useful. Now: each has a number it is supposed to move, checked quarterly; those that do not move it are removed.
What we now apply to every client project
Start with the event a person keeps forgetting. Keep each automation small and single-purpose. Set the interrupt budget before the first alert. Put AI on drafting and classifying with a review step, never on deciding. Give every automation an owner, a log and a switch. Measure one number per automation and remove what does not move it. And run the client’s automations the way we run our own, because we will be asked, and the answer should be that we do.
What this means for you
We automate our own intake, monitoring, reporting, quality gates, support classification, updates, access reviews and invoicing, and we removed the automations that were noisy, clever or ownerless. The lessons, small and event-triggered, owner and log and switch, AI for drafting with review, one number per automation, are the ones we apply to every client project, because they were learned on our own systems first.
Frequently asked questions
Why write about your own automations?
Because it is the honest way to show what works. We recommend automation to clients, and the credibility of that advice depends on whether we run our own company the way we suggest. We do, imperfectly, and the imperfections taught us more than the successes. The lessons below are the ones that changed how we build for clients.
What did you get wrong?
We over-alerted, so an important alert was missed among unimportant ones. We built a clever content generation flow that produced pages nobody would have been proud of and removed it. We let an automation run without an owner and found out it had been failing silently for weeks. Each was a design mistake we now check for on every client project: interrupt budget, review before publish, ownership and monitoring for the automation itself.
Where does AI fit in your own work?
Drafting: monthly report narratives, first versions of documentation, metadata and alt text, replies to routine enquiries. Classifying: incoming requests by type and urgency, monitoring alerts by likely cause. Explaining: inherited code and long threads. Never deciding: what to build, what to deploy, what to send. A person reviews and owns every output that leaves the building, and that review is where the quality comes from.