Don’t change the way you work for the sake of automation

The right question is the other way round: can automation work the way you already do? A semi-technical note from a parish office in Aylesbury, where a centuries-old publishing format meets a five-minute digital workflow.

There is a parish office in Aylesbury that runs three Catholic churches on a small team working part time. Every week they produce a newsletter: Mass times, notices, baptisms, funerals, collection totals, upcoming events, the sick list. It is assembled from all over the parish, laid out in a template, printed, and picked up at the door by thousands of people on their way out of Mass.

It is also, and this is the part most consultants miss, a publishing engine. The team gathers news from across three churches, edits it, structures it into a known format, and ships it on a weekly deadline, every week, without fail. That is not an old-fashioned process waiting to be replaced. That is an editorial operation most content teams would envy, running on a template that has worked since the printing press. Hundreds of years of iteration have gone into the parish newsletter as a format. It works.

The problem was never the paper. The problem was that thousands of other people go to the website instead, and the website needed the same information, and getting it there meant somebody retyping the newsletter into the site by hand. The best part of an hour, every single week, on top of everything else three churches ask of a part-time team. When time ran short, the site slipped behind, and a parish website with last week’s Mass times is worse than no website at all.

The advice they would normally get

Here is what the standard playbook says to a team like this: go digital-first. Put the newsletter into a content system, publish to the web as the primary format, generate a print version as an output. Retrain the volunteers. Change the template. Modernise the workflow.

And here is why that advice is wrong, not just unkind but analytically wrong. Thousands of people walk through the door and pick up the paper. Thousands visit the website. Neither audience is optional, but only one of the two formats has to be produced by hand, by this team, in this office, with these volunteers, some of whom have been assembling this newsletter for years and are extremely good at it in the format they know. The paper is the artefact that matters most for the situation. It is where the editorial judgement lives, where the deadline discipline lives, where the institutional memory lives.

So the question we asked was not “how do we move this team onto a digital workflow?” It was: the workflow already exists and already works, so can the automation meet it where it is? Take the paper. Parse it. Sort it. Publish it. Let the humans keep doing the thing humans are good at, and let the machine do the retyping.

That is the whole thesis, and it generalises far beyond a parish. If an automation project starts by asking your team to change how they work, be suspicious. The best automation is invisible at the point of work: it picks up the artefact your process already produces and carries it the rest of the way.

The workflow, semi-technically

Here is what actually happens each week now, end to end.

1. The team builds the newsletter exactly as they always have. News assembled from across the three churches, laid out in the same template, finished as a document for printing. Nothing about this step changed. That was the design requirement, not a compromise.
2. Someone uploads the finished newsletter to the website. One screen, one button: select the file, press process. This is the only new step in their week.
3. The text is extracted, with one special case. Most of the document extracts as plain text. But the Mass times table is a genuine table, and tables collapse badly when you flatten them to text: columns interleave, days detach from times, times detach from intentions. So the system reads that section positionally instead, using where each fragment of text physically sits on the page to rebuild the columns, day, time, intention, and group them into lines and day-bands. More on why in a moment.
4. AI reads it and sorts it. The extracted text goes to a language model with a carefully built brief: sort every item into its bucket, Mass times, notices, baptisms, funerals, sick list, collections, events, and return the result as structured data, effectively a tidy JSON file, with dates and times in strict formats. The brief is generated fresh each run and includes today’s date, which turns out to matter.
5. A validation layer checks the machine’s homework. Deterministic code, no AI, verifies every date is a real date, every time is a real time, every location and category matches a known list, and anything odd is flagged as a plain-English warning rather than silently accepted. Nothing the model says is trusted raw.
6. A person reviews everything. Every extracted item lands on one review screen with a tick box. The reviewer reads, edits anything that needs it, unticks anything that should not go through, and sees a flag wherever the system spotted a probable duplicate of something already published. Nothing, ever, publishes without this step. This is the line we will not move: the machine proposes, a person disposes.
7. Approved items are written to their homes. Mass times into the Mass times table, replaced fresh each week. Events, notices, baptisms, and funerals each into their own section, each with its own duplicate rule, so the same announcement never appears twice. News into the news feed.
8. The site tidies itself. On a schedule, events retire after they have happened, notices step down after a few weeks, and the more sensitive items expire on a respectful timetable. Nobody has to remember to clean up.

Upload, review, approve. About five minutes where an hour used to go. The running cost is roughly three pence per newsletter, because the job does not need an expensive model, it needs a well-briefed cheap one with a validator standing behind it.

Running it through life

No automation survives contact with reality unchanged, and pretending otherwise is how projects die. Two real examples from this one, because the fixes are more instructive than the build.

The year that wasn’t there. One week the newsletter, quite reasonably, contained no year anywhere: parish newsletters say “Sunday 28th June”, not “Sunday 28th June 2026”. Asked to produce strict dates, the model picked a year, and picked wrong. Downstream, the Mass times system uses the newsletter’s date range to decide when the weekly schedule is authoritative, so a wrong year quietly meant the real week fell outside coverage and the site fell back to default times. The fix came in two layers: the brief now includes today’s date and an explicit rule to choose the year nearest to it, and the validation layer independently re-anchors every date in the payload, trying the neighbouring years and keeping whichever lands closest to today. Belt and braces, so that even if the first layer ever fails on a stranger document, the second still catches it before a human ever sees it.

The table that fell apart. Flattened to plain text, the Mass times table would occasionally scramble, and a scrambled schedule is the one error a parish website cannot afford. Hence the positional reader in step 3. The detail worth stealing is its failure mode: if it cannot confidently find the table’s structure, at least three day labels, real clock-times, it returns nothing at all, and the system falls back to the old path unchanged. It fails closed. It never invents structure to be helpful. If a machine is going to be wrong, it should be wrong by saying nothing, not by making something up, and the review screen means a person will spot the gap either way.

That is what “running it through life” looks like: not a launch and a walk-away, but small, principled tweaks when the real world produces a document the design had not met yet. The system is better now than at launch because it has been used.

What the parish got, and what to steal

The parish office got their hour back, every week, permanently. The Mass times page, the page that matters most to someone standing outside a church door, stays right without anyone editing it. Time-sensitive community news goes out while it is still news. And the team’s actual craft, gathering, judging, and assembling the parish’s news, was not modernised, retrained, or disrupted. It was respected.

“I am still blown away by what it does!!” — Elaine, Parish Administrator

If you run a team with a weekly ritual like this, a report assembled by hand, a document retyped between systems, a publication that exists twice because two audiences need it, the questions to take from this are simple. What artefact does your process already produce? Which format matters most for your situation, and could the others be derived from it? Where must a person stay in charge, and can everything on either side of that person be quietly automated? And when the automation is wrong, does it fail by stopping, or by inventing?

We wrote before about what should not be automated; this is the companion piece about what should, and how to do it without bulldozing a workflow that works. The full story of the build is in the case study, and the discipline behind it, map the process first, automate the highest-return step, keep a person in charge, is how we run every automation engagement.

If your team loses hours a week to a job like this: tell us where the days go and we will map it. Get my readiness review · or book a call: thirty minutes, free, no slides, with a one-page note in your inbox afterwards, whether or not we work together.