Resources · automationagenciesoperations
Agency capacity planning automation - warn before the calendar lies
Agency capacity planning automation should warn when the calendar and the work disagree. Compare three numbers for each team or project: committed hours, actual hours, and work waiting on a client. Send a person an exception list, not a prettier dashboard.
The owner decides whether to delay, re-scope, or staff the work. The system's job is to make that decision early enough to matter.
Which three numbers make capacity honest?#
| Number | What it means | What it can hide alone |
|---|---|---|
| Committed hours | Work already promised for the period | The work may be larger than planned |
| Actual hours | Time already spent or recorded | The client may still be blocking the next step |
| Client-blocked work | Work that cannot move without a decision or asset | A full calendar may not be productive work |
Add one more field to the alert: the next deadline affected. That turns a general warning into a decision someone can act on. An overdue client approval should be visible here because it changes the real delivery plan.
What should trigger an exception alert?#
Use simple, owner-written rules. Flag a project when actual time is higher than the current plan, when committed work has no assigned capacity, or when a client-blocked decision is close to the next delivery date. The exact threshold depends on how an agency estimates work, so it should not be copied from another business.
Do not turn this into a list of capacity software. A planning tool may hold the calendar. The exception layer joins the signals that sit in different places and asks a human to explain the mismatch.
How does the capacity-warning build actually go?#
We first agree the definitions of committed, actual, and blocked work. We map where each one lives today, usually in a project plan, time record, and approval or client-request list. The agency keeps those definitions and the rules for what deserves a warning.
The build reads the agreed totals on a schedule and makes a short exception table. It can link back to the project and list the affected deadline. It does not move tasks, change a client deadline, or allocate a person. A delivery lead reviews the list and records the decision.
We shadow-run it against a completed month. The team looks for alerts it would have raised and compares them with the moments a project actually became difficult. If it warns on normal work, the definition needs work. If it misses a real problem, a source or rule is absent. Only then does it become a routine warning.
Scope changes also belong in the view. An unapproved request can create work that is not in committed hours yet, which is why the scope-creep log feeds the warning rather than staying in a separate spreadsheet. Stable weekly planning tasks should first pass the recurrence audit.
What should you do with next week's plan?#
For each active project, write the three numbers and the next decision waiting on a client. Do not solve the problem yet. Just find the projects where the numbers disagree. Those are the ones worth discussing before the calendar tells a false story.
Where does this fit with the rest of the operation?#
The capacity alert belongs after the basic delivery sequence in scaling an agency without hiring, not before it. Its small watcher uses the same reliability check as automations that fail silently.