Your practice
You scope the project with your client and set its price - a project is never silently folded into the per-user rate.
Project and rollout capacity
What actually counts as "quoted separately."
The phrase repeats across the Services, Plans, and Margin and Billing pages without ever being defined anywhere. This page does that: what counts as a project - office moves, new-site setup, rollouts - as opposed to routine work, and how your practice requests it.
Delivery team
We take a defined project brief - an office move, a new-site setup, a hardware or software rollout - and deliver it as a bounded piece of work with its own start and finish.
A bounded project, from brief to close-out
For work that has a clear beginning and end - unlike the recurring per-user service - and shouldn’t be quietly absorbed into routine support.
What we need first
A written brief: what’s moving or being deployed, the site(s) involved, the timeline your client expects, and who approves a scope change along the way.
What’s included
- Planning and execution against the agreed project brief
- A single point of coordination for the project’s duration
- A close-out note when the project’s scope is complete
Handled separately
- Treating an open-ended request as a project just because it’s large
- Absorbing project work into the monthly per-user anchor
- Deciding your client’s budget or contract terms for the project
What you get: A project that starts and ends on a defined brief, with scope changes surfaced as a decision instead of quietly expanding the original price.
What we hand back: A project close-out note: what was delivered, what’s still open, and who owns it next.
What usually counts as a project, not routine work
Office or site moves
The physical relocation of a location’s IT.
New-site setup
A location that didn’t have infrastructure before.
Planned rollouts
A new application, a device refresh, or a platform migration across a group of users.
Anything routine work would otherwise have to file as an unplanned exception
If a request consistently outgrows what the delivery-model page describes as the routine path, that’s the signal it’s a project.
What this line doesn’t include
- An open-ended "help us go faster" engagement with no defined brief
- A guaranteed timeline set before scope is closed
- Ongoing administration after close-out - that returns to the regular service
Straight answers on project capacity
How do we request project capacity?+
With a written brief - what’s moving or being deployed, the sites involved, the timeline you’re targeting - sent through the usual channel. No passwords or tenant secrets in the brief.
What if a routine ticket turns out to be a project?+
That happens, and it’s the exact signal to watch for: if scope grows past what a routine ticket can reasonably cover, we flag it so a project brief and a separate price get agreed before work continues.