Capacity planning
Plan the shape of recurring demand before choosing how much delivery to move.
User count alone does not describe workload. A useful capacity conversation includes request mix, environment consistency, tooling, access, approval friction, seasonality, and the work that must remain with the partner.
Build a demand picture without manufacturing a forecast.
Use ranges and representative examples when reliable history is unavailable. Do not turn a guess into a promised staffing ratio or response commitment.
Recurring lane
Name the support, Microsoft 365, endpoint, or baseline tasks that repeat often enough to standardize.
Bring:Representative request types and known exclusions.Demand shape
Separate steady work from onboarding spikes, projects, seasonal peaks, and emergency events.
See how seasonal demand changes the model for accounting and bookkeeping firms.
Bring:High/normal/low periods and the reasons behind them.Environment variance
Count the differences that change handling: tools, tenants, device patterns, permissions, and legacy exceptions.
Bring:A non-sensitive environment pattern, not an export.Decision friction
Identify how often routine work pauses for client, partner, vendor, or security approval.
Bring:One routine path and one blocked path.Planning table
Assign each demand type to the right operating lane.
| Demand type | Likely lane | Qualification question | Do not assume |
|---|---|---|---|
| Repeatable user request | Candidate for recurring fulfilment | Is the request included and is authority clear? | Every user issue is supported. |
| Microsoft 365 administration | Candidate within agreed permissions | Which tenants, roles, and approval steps apply? | All security or project work is included. |
| Endpoint routine | Candidate where tooling aligns | Are devices enrolled, supported, and reachable? | Unknown or legacy devices fit the lane. |
| Project or migration | Separate qualification | What outcome, dependencies, and change window exist? | A monthly band covers project effort. |
| Incident or urgent exception | Escalation path | Who owns response decisions and communication? | An uncontracted SLA or incident service exists. |
Choose a controlled starting unit
A starting unit should be large enough to reveal the operating pattern and small enough to correct without disrupting every client relationship.
Possible boundaries
- One qualified service family across a defined client set
- One client segment with similar tools and expectations
- A repeatable request lane currently constraining senior staff
- A new offer launched to future clients before migration of existing ones
The right boundary depends on risk and readiness, not a universal pilot formula.
Capacity signals that require redesign first
- Most requests lack entitlement or client context.
- Every change needs a different informal approver.
- The offer depends on one person’s undocumented memory.
- Tools and access differ without an inventory.
- Urgent work is expected but no escalation owner exists.
Bring demand shape, not a made-up volume target.
A fit conversation can then test the delivery lane, assumptions, and information still needed.