Proposal · Ads × Call Capacity
Right now a person decides when to switch our Google Ads on and off, based on how busy the call calendar looks. This proposal makes that automatic — the ads throttle themselves to match real booking capacity, and tell us when something's wrong.
July 2026 · Internal Feasibility Document
Where We Are
The ads feed the call calendar. The calendar has limited capacity. Getting the balance wrong hurts us in both directions — and today the balance is kept by a human checking manually.
The core issue isn't the strategy — it's the reaction time. The right move (ads on / ads off) changes as bookings come in and slots open up, sometimes within hours. A person checking occasionally will always lag behind. Software checking every hour won't.
Good News
We reviewed both of our plugins in detail. The two hard problems — knowing our real capacity, and having a live connection to Google Ads — are already solved and running on the live site.
The Gap
Everything below is buildable — this is the actual new work, and it's modest compared to what's already in place.
| Missing piece | What it means | Size |
|---|---|---|
| The "how far out?" number | Slot Tracker counts slots but never answers "how many days until the next free slot?" — the single number that tells us people are being pushed to book too far ahead. A small extension to logic that already exists. | Small |
| The decision engine | Nothing currently compares capacity against thresholds and decides "ads should be on/off right now". This is the brain of the feature: simple rules, checked every hour. | Medium |
| The on/off switch | Attribution Tracker only reads from Google Ads today. Adding the ability to pause/enable specific campaigns is a thin layer on the existing connection. | Small |
One thing to verify before the automated phase: our Google Ads API access level must permit changes, not just reads (a 30-second check in the Google Ads account). Since we already pull live production data, this is almost certainly fine — and the warning-only phase doesn't need it at all.
The Mechanism
No AI, no black box — a thermostat. It measures the calendar, applies rules we set, and acts (or warns). Every decision is logged with the numbers behind it.
Read the calendar: free slots over the next few days, and how far away the next available slot is.
Compare against thresholds we choose. Is there enough near-term capacity to justify paid traffic?
Pause or enable the chosen campaigns (or just warn, in phase one) — and email the team either way.
| What the calendar shows | Ads decision | Why |
|---|---|---|
| Next free slot is 3+ days away, or fewer than N slots free in the next 3 days | Pause ads | New enquiries would book far out, where conversion collapses — spend is being wasted. |
| Free slots today and tomorrow, ads currently paused | Enable ads | Capacity is sitting empty — every quiet hour is lost revenue. This is the "no calls today" scenario. |
| Capacity in the healthy middle band | No change | The system deliberately does nothing — no flip-flopping at the edges. |
| Calendar data missing or stale (e.g. tracking broke) | Warn, don't act | The system never makes changes on bad data — it asks a human instead. |
Threshold values above are illustrative. Phase 2's dry run (below) is how we find the right numbers before anything is automated.
The Rollout
We don't hand over the keys on day one. Each phase delivers value immediately and builds confidence for the next — and we can stop at any phase and still be better off than today.
Every hour, the system checks the calendar and emails the team when the balance is off: “Next free slot is 4 days out — consider pausing ads” or “12 slots free in the next 2 days and ads are paused — consider enabling.”
A human still flips the switch — but nobody has to remember to check, and a quiet day never comes as a surprise again.
The full decision engine runs, but instead of touching Google Ads it logs what it would have done: “Tuesday 10:00 — would have paused Campaign X (2 slots left in 3 days).”
We compare its decisions against what the team actually did and tune the thresholds until we trust it. No risk, real evidence.
The system pauses and enables the agreed campaigns itself, within the guardrails below. Every action triggers an email with the reason and the numbers. One click turns the whole thing off and returns control to the team.
Total effort across all three phases: roughly a week of development, spread across the two existing plugins, plus the dry-run observation window. Phase 1 alone solves the “nobody noticed” problem and could be live within days of a go-ahead.
Trust & Control
Software touching live ad spend deserves healthy suspicion. These constraints are part of the design, not afterthoughts — most of the Phase 3 build effort goes here, not into the on/off switch itself.
The system can only act on campaigns we explicitly put on its list. Everything else in the account is invisible to it. It never creates, deletes or edits anything — pause and enable only.
Separate "pause" and "enable" thresholds with a gap between them, plus a minimum time in each state — so one booking can't make the ads bounce on and off all afternoon.
Each pause or enable sends an email with the exact calendar numbers that triggered it. The team is never surprised by the account's state.
Every decision — including "checked, did nothing" — is logged with a timestamp and the data behind it, reviewable on a dashboard at any time.
A single toggle disables all automation instantly and hands control back to the team. Manual changes in Google Ads always win — the system backs off rather than fights.
If calendar data is stale, missing or looks wrong, the system takes no action and raises a warning. It never acts on numbers it can't trust.
Scope
The Ask
Approve Phase 1. Within days, no imbalance between ad spend and call capacity goes unnoticed for more than an hour — and we'll have the data to decide, calmly, whether to let it steer.