Skip to main content
CharleOS uses a value-based billing model that rewards efficiency while protecting clients from cost overruns. Instead of billing raw hours logged, a formula determines what’s chargeable based on quoted estimates and actual delivery.

​
The Core Formula

Every task is billed using this formula:
The Billing Formula
Billable = MIN(maximum, MAX(average, actual))
Where:
  • average = Midpoint of the t-shirt size range (the quoted estimate)
  • maximum = Upper bound of the t-shirt size range (the cap)
  • actual = Time actually logged by the team

​
How It Works

The formula creates three possible outcomes depending on how long the work actually takes:
Scenario: Work completes faster than the quoted averageFormula result: Bill the average (not the actual)Example:
  • Quoted: M (3-6 hours, average 4.5 hours)
  • Actual: 3 hours
  • Billable: MIN(6, MAX(4.5, 3)) = MIN(6, 4.5) = 4.5 hours
  • Banked: 1.5 hours (efficiency gain)
✅ Agency wins: Completed efficiently and created 1.5 hours of banked time (profit margin)✅ Client wins: Pays the average as quoted, not more for slower work

​
T-Shirt Sizing

Work is estimated using t-shirt sizes that represent time ranges:
SizeTime RangeAverageMaximumWhen to Use
XS0-30 mins15 mins30 minsTiny fixes, small text changes
S1-2 hours1.5 hours2 hoursSimple updates, minor features
M3-6 hours4.5 hours6 hoursStandard features, moderate complexity
L8-16 hours12 hours16 hoursComplex features, multiple components
XL24-40 hours32 hours40 hoursMajor features, significant work
XXL40-120 hours80 hours120 hoursVery large deliverables, multi-week work
Averages are rounded to the nearest 15 minutes for clean scheduling. The midpoint calculation may result in values like 22.5 mins, which round to 15 or 30 mins for practical use.

​
What’s Included in the Size?

T-shirt sizes represent the total time needed to complete the deliverable, including:
  • Core work (80%): Design, development, or implementation
  • QA and feedback (20%): Testing, fixes, client feedback rounds
QA time and client feedback are included in the t-shirt size, not added on top. A Medium task (3-6 hours) includes core work PLUS QA/feedback within that range.

​
Per-Requirement Billing

Billing is calculated per requirement, not per task. This provides granular tracking and prevents masking issues.

​
Why Per-Requirement?

Tasks often have multiple requirements (e.g., design + development). If billing was calculated only at the task level: Problem scenario:
  • Design: 2 hours under budget (banked)
  • Development: 2 hours over budget (overage)
  • Task total: 0 net (hides both the efficiency and the problem)
With per-requirement billing:
  • Design: +2 hours banked ✓ (visible)
  • Development: -2 hours overage ⚠️ (visible)
  • Reports show both metrics separately for analysis

​
Requirement Types

Design

Visual design work including:
  • Initial design
  • Client design feedback
  • Design revisions

Development

Code work including:
  • Implementation
  • Internal QA fixes
  • External QA fixes
  • Deployment
Each requirement has its own t-shirt size and billing calculation. Task-level billing is the sum of requirement-level billing.

​
Worked Examples

​
Example 1: Efficient Delivery (Banked Time)

Task: “Homepage Redesign”
  • Requirement: Design, sized M (3-6 hours)
  • Team logs: 3.5 hours
  • Calculation:
    • Average: 4.5 hours
    • Maximum: 6 hours
    • Actual: 3.5 hours
    • Billable = MIN(6, MAX(4.5, 3.5)) = MIN(6, 4.5) = 4.5 hours
  • Result: 1 hour banked (4.5 - 3.5)
What this means:
  • Client is billed 4.5 hours (as quoted)
  • Agency worked 3.5 hours
  • 1 hour of efficiency creates profit margin
  • Team should be rewarded for efficient work

​
Example 2: On-Target Delivery

Task: “Add Blog Integration”
  • Requirement: Development, sized L (8-16 hours)
  • Team logs: 14 hours
  • Calculation:
    • Average: 12 hours
    • Maximum: 16 hours
    • Actual: 14 hours
    • Billable = MIN(16, MAX(12, 14)) = MIN(16, 14) = 14 hours
  • Result: No banked time or overage
What this means:
  • Client is billed exactly what was worked
  • Estimate was accurate
  • No profit margin, but no loss either

​
Example 3: Overrun (Overage Absorbed)

Task: “Build Product Catalog”
  • Requirement: Development, sized L (8-16 hours)
  • Team logs: 20 hours
  • Calculation:
    • Average: 12 hours
    • Maximum: 16 hours
    • Actual: 20 hours
    • Billable = MIN(16, MAX(12, 20)) = MIN(16, 20) = 16 hours
  • Result: 4 hours overage (20 - 16)
What this means:
  • Client is billed 16 hours (the maximum)
  • Agency worked 20 hours
  • 4 hours of overage are non-billable (absorbed)
  • Triggers review: Why did we underestimate?

​
Example 4: Multi-Requirement Task

Task: “Checkout Flow Redesign”
  • Design: M (3-6 hours, avg 4.5)
    • Logged: 4 hours
    • Billable: MIN(6, MAX(4.5, 4)) = 4.5 hours
    • Banked: 0.5 hours
  • Development: XL (24-40 hours, avg 32)
    • Logged: 36 hours
    • Billable: MIN(40, MAX(32, 36)) = 36 hours
    • Overage: 0 (within range)
Task totals:
  • Quoted: 36.5 hours (4.5 + 32)
  • Actual: 40 hours (4 + 36)
  • Billable: 40.5 hours (4.5 + 36)
  • Net: +0.5 hours banked
Analysis:
  • Design was slightly efficient
  • Development took longer but stayed under maximum
  • Overall: Small efficiency gain despite development taking longer

​
The 80/20 Split

T-shirt sizes are internally allocated using an 80/20 split for scheduling purposes:

​
How the Split Works

Core Development: 80%
  • Writing code
  • Initial implementation
  • Feature completion
QA Buffer: 20%
  • Internal QA review time
  • Fixing bugs found in QA
  • External QA feedback fixes
  • Multiple fix rounds draw from this pool
Example (M size, 270 minutes total):
  • QA budget: 60 minutes (20% = 54 mins, rounded UP to 60)
  • Development: 210 minutes (270 - 60 = 210)
The 80/20 split is for internal scheduling only. Clients don’t see this breakdown—they see the total t-shirt size. The split helps PMs allocate work to the right people, but it doesn’t change billing.

​
The 20% Pool

The 20% buffer is a shared pool for all review-related work: For Development:
  • Internal QA finds 3 bugs → fixes come from the 20%
  • Client UAT finds 2 more bugs → fixes also come from the 20%
  • Once the 20% is exhausted, additional fix time is overage
For Design:
  • First client feedback round → uses part of the 20%
  • Second feedback round → uses more of the 20%
  • Third round pushes into overage if pool is depleted
This incentivizes:
  • Getting designs right the first time
  • Thorough internal QA before client review
  • Clear communication to minimize feedback rounds

​
Key Billing Terms

TermDefinitionExample
Quoted MinutesAverage of the t-shirt sizeM = 270 mins (4.5 hours)
Quoted Max MinutesMaximum of the t-shirt sizeM = 360 mins (6 hours)
Actual MinutesSum of logged time entriesTeam logs 210 minutes
Billable MinutesResult of the formulaMIN(360, MAX(270, 210)) = 270 mins
Banked MinutesEfficiency gain (average - actual)270 - 210 = 60 mins banked
Overage MinutesNon-billable excess (actual - max)If actual = 400, overage = 40 mins
Budget Used %Actual as % of maximum210 / 360 = 58%

​
When Hours Are Deducted

Hours are deducted from the client’s retainer allocation in real-time as work is logged, but the billable amount (not raw logged time) is what counts.

​
The Flow

1

Time Entry Logged

Team member logs time to a task or subtask
2

Billing Calculated

System calculates current totals:
  • Sum all logged time for the task
  • Apply billing formula per requirement
  • Aggregate to task level
3

Client Balance Updated

Billable hours (not raw logged) are deducted from monthly allocation:
  • Hours used = Sum of billable across all tasks
  • Hours remaining = Monthly allocation - hours used
4

Client Sees Update

Client portal shows updated remaining balance in real-time

​
In-Progress vs. Completed

While work is in progress:
  • Client sees actual logged time (may be less than what they’ll be billed)
  • Formula not yet finalized
When task is completed:
  • Formula is applied
  • Billable amount may jump to the average (if under)
  • Client is billed the final calculated amount

​
Why This Model Works

Teams are incentivized to:
  • Work smart, not just fast
  • Do it right the first time (avoid rework)
  • Build reusable components
  • Improve processes
Banked time = profit margin = bonus potential
Clients have cost certainty:
  • Maximum is always capped
  • No surprise invoices
  • Risk is shared fairly
  • Focus on value, not hours
Over-runs hurt the agency, so:
  • Teams learn from past tasks
  • Estimates get more accurate over time
  • Complexity is accounted for upfront
  • Scope is clarified before work starts
Both sides win:
  • Client: Cost capped, fair pricing
  • Agency: Efficiency rewarded, overruns limited
  • Team: Quality matters more than speed

​
Common Scenarios

​
Scenario: Consistent Banked Time

Situation: Team consistently finishes 10-15% under estimates What it means:
  • ✅ Efficient delivery
  • ✅ Good estimation (realistic but beatable)
  • ✅ Strong profit margins
  • ⚠️ Consider: Are estimates too conservative?
Actions:
  • Celebrate and reward efficiency
  • Review if estimates can be tightened
  • Share best practices across team

​
Scenario: Consistent Overage

Situation: Tasks consistently exceed maximum by 20-30% What it means:
  • ⚠️ Chronic underestimation
  • ⚠️ Scope creep
  • ⚠️ Technical debt slowing delivery
  • 🔴 Profitability issues
Actions:
  • Review estimation process
  • Analyze overage patterns (which types of work?)
  • Tighten scope management
  • Consider larger t-shirt sizes

​
Scenario: Mixed Performance

Situation: Some tasks banked, others overage, net neutral What it means:
  • ✅ Normal variation
  • ⚠️ May be masking issues
  • Need granular analysis
Actions:
  • Review per-requirement metrics
  • Identify patterns (design vs dev performance)
  • Train on specific areas with issues
  • Maintain overall balance

T-shirt Sizing

How to estimate work using t-shirt sizes for accurate billing

Efficiency

Deep dive into banked time, overage, and profitability impact

Day Rates

How the billing model affects day rate calculations

Time Tracking

How to log time that feeds into billing calculations