Internal operations
Running a two-person operation at high automation leverage
Lingows runs core parts of its own operation, research intake, content pipelines, lead routing, and QA, through automation with human review gates. This is a description of the mechanics: what we automated, what compounded, what we left alone, and where it broke.
- This describes how our own two-person operation runs, not a client engagement.
- No percentages or hour figures appear here on purpose. What follows is the mechanics, not a claimed outcome.
- Automation with a human review gate is not the same as unattended automation. We distinguish the two throughout.
Last reviewed 2026-08-10
What we automated first
The first target was intake, specifically research and reporting intake. Before any automation, pulling data for a client report meant logging into several dashboards, exporting numbers by hand, and pasting them into a document. We replaced that with scheduled jobs that pull from each data source on a fixed cadence and land the results in a shared structure that later steps can read directly.
Intake was the right starting point because it is repetitive, rule-based, and low-judgment. There is no creative decision in pulling last month's conversion numbers from an ad platform. Automating it first meant every downstream step, reporting, alerting, and content, had a reliable input to work from instead of a manually assembled one.
Content pipelines with review gates
Content production is broken into stages: a research stage that gathers source material and existing internal data, a drafting stage that produces a first pass, and a review stage where a person reads the draft against the source material before anything publishes. The drafting stage is automated. The review stage is not, and we do not intend for it to be.
The review gate is not a formality. A draft that fails review gets sent back with specific notes rather than published with light edits. That feedback loop is itself somewhat structured: recurring correction patterns get written into the instructions the drafting stage uses next time, so the same mistake does not have to be caught twice.
Lead routing
Inbound leads arrive from several channels: the contact form, the free SEO report tool, and direct email. Each one used to require someone to notice it, read it, and decide who should follow up. We built routing rules based on the source and the content of the submission, so a request that names a specific service routes to whoever handles that service, and everything else lands in a shared queue with the context already attached.
Routing does not include qualification or a response. It only gets the right information in front of the right person faster than manual triage would. A human still writes every reply.
QA checks
Before anything publishes, a set of automated checks runs against it: broken links, missing metadata, banned phrases from our own style rules, and inconsistent contact information across pages. These checks do not approve content. They flag problems so a person does not have to manually scan for the same recurring mistakes on every single page.
The QA layer grew directly out of mistakes we actually made. The banned-phrase check exists because we once published a page with an old phone number still in the footer. Each check in that list corresponds to something that happened once and that we decided should never require a human to catch a second time.
Publishing
Once a piece of content clears review and QA, publishing itself is automated: the build runs, the page deploys, and it is live without a manual deploy step. This is the least interesting part of the pipeline and also the part most people assume is the hard one. It is not. Getting a good draft and catching its mistakes is the hard part. Pushing a button was never the bottleneck.
What compounded
The gains did not come from any single automated step. They came from the fact that each stage's output became the next stage's clean input. Reliable intake meant reporting could run on a schedule instead of being blocked on someone remembering to pull numbers. Reliable QA meant review could focus on substance instead of catching footer typos. Each improvement freed the next stage to focus on a narrower, more valuable problem.
The other compounding effect was institutional memory. Every correction made during review became an instruction for next time, so the drafting stage got measurably better at avoiding the same category of mistake without either of us deciding to sit down and retrain it deliberately. It happened as a side effect of doing the work.
What we deliberately did not automate
Strategy decisions, which client work to take on, and any judgment call about tone or positioning stay entirely manual. We do not automate the final review of published content, ever, regardless of how consistent the drafting stage becomes. And we do not automate replies to inbound leads. Routing gets information to a person faster. It does not write the response.
The line we draw is: automate the parts where a mistake is cheap and recoverable, and keep a human on the parts where a mistake is expensive, public, or represents a real relationship. Publishing a page with a typo is cheap to fix. Sending a client an automated reply that misreads their situation is not.
Where it broke
The first version of the intake automation silently failed when one data source changed its export format, and nobody noticed for a stretch of time because the job did not error, it just returned stale data that looked plausible. We fixed this by adding a freshness check that flags data that has not changed when it should have, rather than trusting the job to succeed just because it ran.
The drafting stage also produced a run of content that was structurally correct but repetitive across pages, because it leaned on the same phrasing patterns once those patterns had been reinforced by earlier corrections. Review caught it, but it took a deliberate pass to notice the pattern rather than judging each page individually. We now periodically compare pages against each other, not just against source material, specifically to catch this.
What this proves about the approach
None of this replaced judgment. It removed the repetitive work that sat in front of judgment, so the two of us spend time on review, strategy, and client relationships instead of data entry and manual triage. The failures we hit were mostly about trusting automation to notice its own mistakes, which it generally cannot, so every automated stage in our pipeline now has a corresponding check that a person reads.
Decisions
The calls that shaped it
Each one had a real alternative. This is why we went the way we did.
Automate intake before anything downstream
Research and reporting intake was rule-based and low-judgment, so it was the safest place to remove manual steps first and gave every later stage a reliable input.
Keep a human review gate on every published draft
The drafting stage is automated. Publication approval is not, and we do not plan to change that regardless of how consistent drafts become.
Route leads, do not respond to them
Automation gets the right context to the right person faster. It does not write or send the reply, because that is a judgment call about a real relationship.
Add a check for every failure, not a fix for one instance
When the intake job silently returned stale data, we added a freshness check rather than a one-time correction, so the same failure class cannot recur unnoticed.
What does Lingows actually automate in its own operation?
Lingows automates research and reporting intake, first-pass content drafting, lead routing by source and content, and QA checks before publishing. Every automated stage has a human review gate before anything goes live, and strategy decisions and lead replies are never automated.
- Scheduled intake jobs replace manual data pulls from client reporting sources.
- Content drafts are automated, but a person reviews every draft against source material before it publishes.
- Leads are routed automatically by source and content, but a person writes every reply.
- QA checks catch recurring formatting and consistency mistakes before publication, not after.
What it proves
The takeaway
- High leverage came from connecting stages, reliable intake feeding reliable reporting feeding faster review, not from any single automated step in isolation.
- Automation with a human review gate at publication caught real problems that a fully unattended pipeline would have shipped.
- The failure modes we hit were about automation not noticing its own mistakes, which is why every automated stage now has a corresponding human or automated check reading its output.
- Judgment calls, strategy, tone, and client replies, stayed manual on purpose and remain manual today.
Where this connects
Related work
Each link explains why it is relevant, not just where it goes.
Want the same architecture behind your own surface
Start with a diagnosis. You get the roadmap and the quote before anyone builds anything.