Automation plan

Which data feeds exist, what each can and cannot do, how much of the 292-task queue they actually remove, and the order to build it in. Researched against the published API documentation on 22 August 2026.
The honest headline: automation removes about a third of the hours, not most of them. The work that looks repetitive — filing, chasing, checking — is repetitive in shape but each instance needs a credential, a decision or a person. What automation genuinely kills is watching: noticing that something changed, and knowing what it means. That is where every serious failure in this portfolio came from, so it is worth doing even though it is not the biggest number.

What each task can realistically become

The feeds that exist

Companies House Streaming API Build this first

Real-time feed of every change to the register, as it happens.
Access Free, API key
Direction Read only
Gives us Status changes, new filings, officer changes, gazette notices
Replaces The entire re-verification job

This is the single highest-value thing on the page. Every serious problem in this portfolio was a change nobody saw: a strike-off gazetted, a director resigned, a deadline passed. One client was monitored by nothing at all for months. A streaming listener turns that from a periodic manual sweep into a same-day alert, and it costs nothing but the build.

Companies House Public Data API Build alongside

Read and search public company data — profile, officers, filing history, charges.
Access Free, API key
Direction Read only
Gives us Verification on demand, deadline dates, officer lists
Replaces Every "re-check the register" step

The streaming API tells you something changed; this tells you what the position is now. Together they replace the manual verification that currently opens every runbook — and they make the intake diff automatic rather than a spreadsheet paste.

Companies House Filing API Needs the partner

Submit filings — the "manipulate company data" suite, for those with authority to do so.
Access Requires presenter authority
Direction Write
Gives us Confirmation statements, address and officer changes
Blocker We are not the filing agent — the partner firm is

Do not build against this before the authority question is settled. Filing still needs the company's authentication code as well as presenter credentials, so this is the piece that depends on the central credential store below.

HMRC APIs — Agent Authorisation and VAT (MTD) Agent credentials required

Request authority to act for a client, and submit VAT returns under Making Tax Digital.
Access Agent services account required
Direction Read and write
Gives us Authorisation requests, VAT submissions and obligations
Sandbox Yes — testable before any real credential exists

The Agent Authorisation API creates and tracks authorisation requests; the VAT MTD API files returns. Both sit behind agent credentials that the partner firm holds, not us. The sandbox is the useful part today — the integration can be built and proven before the authority is in place, so nothing waits on paperwork.

Registry Trust — CCJ and judgment data Commercial, paid

The statutory register of judgments, orders and fines, maintained on behalf of the Ministry of Justice.
Access Paid — bulk supply or per-search
Direction Read
Gives us Judgments against a client, and monitoring alerts on new ones
Notable No permission needed and no footprint left on the subject

They offer monitoring, not just search — notification when a judgment is registered against a company on the list. That is a genuine early-warning signal about a client in trouble, and it arrives long before anything shows at Companies House. Price it before committing: it is the only paid feed here and the value depends entirely on the cost per company.

The central credential store

Everything that writes depends on this, and it is the most dangerous thing in the system. Filing needs the company's authentication code. We hold of them; the partner needs them at the moment of filing and at no other time. A shared spreadsheet of authentication codes is a catastrophe waiting for one forwarded email.

Build it as a vault, not a list. Access per company rather than per folder, every read logged with who and when and why, credentials never rendered into a page that can be printed or forwarded, and issued to the partner for a filing window rather than held by them permanently. The current pack shows codes in plain HTML, which is fine for one trusted operator and not fine the moment a second party can reach it.

The biggest block — portal and social

Portal setup is 44 hours and social is 55 — together 99 of the 207, nearly half the estate. Both are the same procedure repeated 44 times, which is exactly what automation is for. But they automate very differently, and the difference is not about effort.

Portal install Genuinely automatable

API Apps Script API — projects.create + projects.updateContent
Scope script.projects
Access Free, OAuth against the client's own Google account
Today 60 min each · 44 hours across the estate

The API creates an empty script project and pushes files into it. That is the whole of steps two and three of the install runbook — create the project, paste the bundle — which is the largest manual block and the one most likely to be got wrong by hand. Each client's Config.gs is already written and already client-specific, so there is nothing to compose at run time: read the config, create, push, run setup.

What stays manual: signing in as the right Google account, and the Business Profile step where Google requires its own verification. Realistically this takes the install from 60 minutes to about 10 — call it 44 hours down to roughly 8.

Verified against the Apps Script API reference, 22 August 2026.

Social account creation Do not automate this

Platforms YouTube, Google Business Profile, Facebook, Instagram, X
Today 75 min each · 55 hours across the estate
Blockers CAPTCHA, phone verification, device fingerprinting
Bigger blocker Every one of them prohibits it in their terms

The friction is deliberate. CAPTCHAs and phone verification exist precisely to stop programmatic signup — so any automation here is an attempt to defeat a control the platform put there on purpose. That is not a technical hurdle to engineer around, it is the platform saying no.

And the downside is asymmetric. A batch of accounts created programmatically from one address tends to be detected together and removed together. We would be trading 55 hours of admin for the risk of losing 44 clients' brand handles at once — including the ones already filled in, linked and handed over. An account nobody can get back into is worse than one that was never created.

Platform automation policies, all five providers.

What the social hour actually contains Automate the other half

Creation is only part of the 75 minutes. Split it and the automatable portion is real:

StepMinutesAutomatable?
Check handle availability across five platforms10Yes — a lookup, no account needed
Create the five accounts30No — see above
Fill profiles — logo, banner, about, links20Partly — Meta and YouTube have APIs once the account exists
Generate and queue the first posts10Yes — already generated from the service list
Record handles and recovery routes5Yes — write back to the client record

So roughly 25 of the 75 minutes is automatable without touching account creation — the handle check, the content, and the write-back. That is 55 hours down to about 37, which is worth having and is nothing like the portal saving.

The honest total. Portal 44 h → about 8. Social 55 h → about 37. 99 hours becomes roughly 45. That is a real saving and it is not the "half the estate disappears" that the raw repetition count suggests — because the repeated thing in social is a human sitting in front of a signup form that is designed to require a human.

The order to build it

Phase 1 · the watcher

Stop being surprised

  1. Register for a Companies House API key — free, same day.
  2. Poll the Public Data API for all companies nightly. Store the response verbatim, not a summary of it.
  3. Diff each response against the last. Raise an alert on any change to status, officers, or a due date.
  4. Feed the diff into the existing intake logic, which already knows how to show what moved and what it does to the task list.
  5. Add the Streaming API once the nightly poll is proven, to move from next-day to same-hour.

Why first: it needs no credentials beyond a free key, it touches nothing that can be broken, and it removes the failure mode that has actually cost this business money.

Phase 2 · the record keeper

Make our own data self-correcting

  1. Auto-resolve the director mismatches — of them — by comparing our record against the officers endpoint and flagging, never silently overwriting.
  2. Same for the nominee reconciliation and the unattributed documents.
  3. Recompute deadlines from the API rather than from our own dates, so a filed statement updates everything downstream automatically.
  4. Publish the whole thing to api/*.json on a schedule, so the pack is always current without anyone running a build.

Flag, do not overwrite. The rule that has protected this estate is recording both values when they disagree. An automated reconciler that silently picks one is worse than the manual process it replaces.

Phase 3 · the vault

Make filing possible without handing over the keys

  1. Move every authentication code out of _data.js and the HTML into a store with per-company access control.
  2. Log every read — who, when, which company, for what filing.
  3. Issue to the partner for a filing window, then revoke. Never a permanent copy.
  4. Only then connect the Companies House Filing API, with the partner's presenter credentials.
Phase 4 · the assisted filings

Prepare everything, submit with one click

  1. Pre-fill confirmation statements from live API data — outstanding today.
  2. Draft every chase and objection letter from the runbook template with the live position merged in.
  3. Build the HMRC integration against the sandbox while the agent authority is being arranged.
  4. Keep a human on the submit button. Nothing in the "they must be present" tasks is ever automated, whatever the API allows.
Phase 5 · the reports

Client reporting off the live feed

  1. Generate each client's status pack from the API rather than from stored files, so it cannot go stale.
  2. Add the CCJ monitoring feed if the pricing works — an early-warning signal that arrives before Companies House shows anything.
  3. Push deadlines into each client's portal calendar, which already exists and is currently populated by hand.

What is never automated

tasks stay human whatever gets built. Passing an HMRC identity check in a director's name, signing a declaration, consenting to act as a director, obtaining a personal identity code — these are not permissions problems that a better-scoped credential solves. They are the point at which a named person takes responsibility. An agent may read, analyse, draft and propose; it may not submit and it may not be the client.

Every automated output should land at Submitted, never at Done. The check before Done is the only quality control in the system, and it matters more once a machine is producing the work, not less.

Realistic expectations

A third of the hours, and most of the risk. The time saving is real but moderate. The risk reduction is the actual return: a register watcher that catches a gazette notice the day it appears is worth more than the fifteen hours a year it saves, because the thing it prevents is a dissolved company.