Purpose
To ensure clients are never billed for unexpected work without prior approval, while protecting britecode from unpaid or disputed invoices related to out-of-scope technical issues.
Scope
This SOP applies to:
A la carte clients
Project-based work
One-off fixes or troubleshooting requests
Any work not explicitly included in the original scope, estimate, or agreement
This SOP does not apply to:
Retainer clients where scope is managed by an account manager
Pre-approved monthly support hours
Definitions
In Scope
Work explicitly listed in the original proposal or agreement
Fixes related to bugs or issues caused by our own code or implementation
Out of Scope
Debugging caused by client data, content, or third-party systems
Issues introduced after launch due to changes, imports, or external integrations
Edge cases or sync failures not identified during original scoping
New requirements or problems discovered after delivery
Step-by-Step Process
1. Identify the Issue
When a problem is discovered:
Determine whether it is:
Our code or setup issue (in scope)
Client data, third-party, or new issue (potentially out of scope)
If unsure, pause and ask before proceeding.
2. Stop Before Fixing
If the issue appears out of scope:
Do not continue work beyond initial discovery
Do not implement a fix
Do not bill time yet
This is the mandatory pause point.
3. Document the Problem
The developer must clearly document:
What the issue is
Why it is occurring
What system or data is causing it
Why it is not part of the original scope
What the impact is if left unresolved
This explanation must be understandable to a non-technical client.
4. Provide an Estimate
Before any work continues:
Estimate the time required (best effort, honest range)
Call out any uncertainty if the issue requires investigation
Break it into:
Investigation time
Implementation time
Example:
“Estimated 2–3 hours to investigate and resolve.”
5. Client Communication and Approval
The developer (or PM, if assigned) must:
Explain clearly that the issue is out of scope
Explain why it is billable
Share the estimated time and cost
Ask for explicit approval in writing (email, ticket comment, or PM tool)
No approval = no work.
6. Proceed Only After Approval
Once approval is received:
Acknowledge approval in the task or ticket
Proceed with the work
Track time accurately
7. Invoice Alignment
Billing should reflect:
Approved scope only
Approved hours or range
Clear description of what was done and why
Invoices should never surprise the client.
Special Notes
Clients with Internal Approval Chains
If the client has a boss or internal approver:
Assume they cannot approve surprise work
Be extra clear and conservative with estimates
Never proceed without written approval
Retainer or Managed Accounts
For accounts managed by an account manager:
Follow the internal approval process
Confirm with the account manager before proceeding
Do not bypass account ownership
What Went Wrong (Learning Rule)
If a client disputes an invoice:
First check whether approval was obtained
If not, that is a process failure, not a billing failure
Use it as a reset point, not a precedent
Golden Rules
No approval, no work
If it’s not in writing, it doesn’t count
Clients hate surprise invoices more than bad news
Pausing to explain saves time and money
Out-of-Scope Approval Email Template (Short)
Hi [Name],
We identified an issue related to [brief issue description]. This is outside the original scope of work and is not related to an issue with our code or setup.
To resolve it, we’ll need to [briefly describe the work].
Estimated time: [X–Y hours].
Please confirm if you’d like us to proceed with this work at our standard rate. Once approved, we’ll move forward.
Thanks,
[Name]