Skip to main content
Efficiency measures how well you’re delivering work compared to estimates. It’s the difference between what you quoted and what you actually delivered—and it directly impacts profitability.

The Core Concept

Efficiency compares two values:

Quoted Time

What you estimated the work would take

Actual Time

What it actually took to deliver
The Formula
Efficiency = (Quoted Time ÷ Actual Time) × 100
Actual < Quoted - You delivered faster than estimated.Example: Quoted 6 hours, delivered in 4 hours = 150% efficiencyThis is good! You’ve created “banked time” that benefits profitability.

How Efficiency Works in CharleOS

CharleOS uses value-based billing that caps how much can be billed, regardless of time spent. This makes efficiency critical:

The Billing Formula

For every task requirement, CharleOS calculates billable time using:
Value-Based Billing
Billable Time = MIN(max, MAX(average, actual))
Where:
  • Average = The quoted time (middle of the t-shirt size range)
  • Maximum = The upper bound of the t-shirt size range
  • Actual = Time actually logged
This creates three outcomes:
Scenario: Actual < Average
Quote: Medium (3-6 hours, average 4.5 hours)
Actual: 3 hours logged

Billable = MIN(6, MAX(4.5, 3)) = MIN(6, 4.5) = 4.5 hours
Banked = 4.5 - 3 = 1.5 hours
You delivered in 3 hours but can bill 4.5 hours. The 1.5-hour difference is banked time—pure profit.✅ This improves day rates and profitability.

T-Shirt Sizing and Estimates

Estimates in CharleOS use t-shirt sizing with time ranges:
SizeTime RangeQuoted (Average)Maximum
XS0.5-1 hour45 mins60 mins
S1-3 hours2 hours3 hours
M3-6 hours4.5 hours6 hours
L6-12 hours9 hours12 hours
XL12-24 hours18 hours24 hours
XXL24-48 hours36 hours48 hours
When a quote is approved and converted to a task:
  • quotedMinutes = average of the range
  • quotedMaxMinutes = maximum of the range
These become the baseline for efficiency tracking.

Requirement-Level Efficiency

Efficiency is tracked at the requirement level, not just the task level. This gives granular insights.

Requirement Types

Tasks can have multiple requirement types:

Design

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

Development

Development work including:
  • Implementation
  • Internal QA review and fixes
  • External QA review and fixes
  • Deployment

SEO

SEO optimization work

Retain

Ongoing maintenance and support
Each requirement is estimated separately using t-shirt sizing, and efficiency is tracked per requirement.

Example: Task with Multiple Requirements

“Redesign Homepage” task:
RequirementSizeQuotedMaxActualBillableBanked/Overage
DesignL (6-12h)9h12h7h9h+2h banked ✅
DevelopmentXL (12-24h)18h24h28h24h-4h overage ⚠️
Task Total-27h36h35h33h-2h net
Analysis:
  • Design was efficient (+2h banked)
  • Development over-ran (-4h overage)
  • Net result: -2h overage overall
This granularity helps identify where efficiency issues occur.

Where to See Efficiency

Efficiency metrics appear throughout CharleOS:
See your personal efficiency for the last 7 days:
  • Total banked minutes
  • Total overage minutes
  • Net efficiency (banked - overage)
  • Status badge: “banking” | “on_track” | “overage”
  • Comparison to previous week
This shows your overall delivery performance.
Each client profile shows efficiency for completed tasks in the current month:
  • Banked minutes
  • Overage minutes
  • Net efficiency
  • Month-over-month comparison
This shows client-level profitability and estimate accuracy.
Each task shows requirement-level efficiency:
  • Quoted time (average)
  • Maximum time
  • Actual time logged
  • Billable time
  • Banked/overage indicators per requirement
This helps you understand efficiency at the granular level.
Managers see team efficiency:
  • Department-level efficiency
  • Individual team member efficiency
  • Trends over time
This helps identify training needs and process improvements.

Efficiency Status

CharleOS categorizes efficiency into three states:
StatusConditionBadgeWhat It Means
BankingNet > 0 GreenCreating banked time, improving profitability
On TrackNet = 0 BlueBreaking even, estimates are accurate
OverageNet < 0! RedLosing time, hurting profitability
Example
Last 7 days:
- Banked: 12 hours
- Overage: 5 hours
- Net: +7 hours
- Status: Banking ✅

How Time Is Tracked

For efficiency tracking, time entries must be linked to:

1. Subtasks

Tasks are broken down into subtasks that map to requirement types: Design Subtasks:
  • Design work
  • Client design feedback
Development Subtasks:
  • Development work
  • Internal QA review
  • Internal QA fixes
  • External QA review
  • External QA fixes
  • Deployment
When you log time to a subtask, it’s aggregated into the appropriate requirement.

2. Time Entry Fields

Each time entry includes:
  • duration - Minutes logged
  • date - When work was done
  • activityType - Type of work (maps to requirement)
  • isBillable - Whether it counts toward billable time
  • taskId or subtaskId - What it’s linked to
Only entries with isBillable = true count toward efficiency calculations.

3. Automatic Aggregation

When time entries are created, updated, or deleted, CharleOS automatically:
  1. Sums actual minutes per requirement
  2. Applies the billing formula
  3. Updates task_requirement.actualMinutes, billableMinutes, bankedMinutes, overageMinutes
  4. Aggregates to task level
  5. Updates task-level efficiency metrics
This happens in real-time, so efficiency metrics are always current.

What Affects Efficiency

Understanding what drives efficiency helps you improve it:

Things That Improve Efficiency (Create Banked Time)

FactorHow It Helps
Accurate EstimatesSetting realistic expectations you can beat
Clear RequirementsLess rework and back-and-forth
Good PreparationUnderstanding the work before starting
Reusable ComponentsLeveraging existing code/designs
Focused WorkMinimizing interruptions and context switching
ExperienceDoing similar work becomes faster
Process EfficiencyStreamlined workflows reduce waste

Things That Hurt Efficiency (Create Overage)

FactorHow It Hurts
Poor EstimatesUnderestimating complexity or time needed
Scope CreepWork expanding beyond original scope
Unclear RequirementsRework due to misunderstandings
Technical DebtWorking around old code slows delivery
InterruptionsContext switching wastes time
Unexpected IssuesBugs, environment problems, dependencies
Learning CurveNew technologies or unfamiliar work

Efficiency and Day Rates

Efficiency directly impacts day rates:
Scenario: You consistently create banked time.Impact on day rate:
  • Same revenue, less time spent
  • Days used is lower
  • Actual day rate increases
Client: £5,000/month, 60 hours allocated

Efficient delivery:
- Billable: 45 hours (banked 15 hours)
- Days used: 45 ÷ 7.5 = 6 days
- Day rate: £5,000 ÷ 6 = £833/day ✅

Inefficient delivery:
- Billable: 75 hours (overage 15 hours)
- Days used: 75 ÷ 7.5 = 10 days
- Day rate: £5,000 ÷ 10 = £500/day ⚠️
Efficiency is the fastest way to improve day rates.

Worked Examples

Example 1: Perfectly On-Target

Task: “Add user profile page”
  • Design: S (1-3h, avg 2h, max 3h)
  • Development: M (3-6h, avg 4.5h, max 6h)
Time logged:
  • Design: 2.5 hours
  • Development: 5 hours
Billing calculation:
RequirementQuotedMaxActualBillableBankedOverage
Design2h3h2.5hMIN(3, MAX(2, 2.5)) = 2.5h00
Development4.5h6h5hMIN(6, MAX(4.5, 5)) = 5h00
Total6.5h9h7.5h7.5h00
✅ Perfectly on target. Estimate was accurate.

Example 2: Efficient Design, Development Overage

Task: “Redesign checkout flow”
  • Design: L (6-12h, avg 9h, max 12h)
  • Development: XL (12-24h, avg 18h, max 24h)
Time logged:
  • Design: 7 hours
  • Development: 28 hours
Billing calculation:
RequirementQuotedMaxActualBillableBankedOverage
Design9h12h7hMIN(12, MAX(9, 7)) = 9h2h ✅0
Development18h24h28hMIN(24, MAX(18, 28)) = 24h04h ⚠️
Total27h36h35h33h2h4h
Net: -2h overage Analysis:
  • Design was efficient (+2h banked)
  • Development over-ran (-4h overage)
  • Net result: losing 2 hours overall
  • Action: Review what caused development overage

Example 3: Everything Under-Estimated

Task: “Build complex reporting dashboard”
  • Design: M (3-6h, avg 4.5h, max 6h)
  • Development: L (6-12h, avg 9h, max 12h)
Time logged:
  • Design: 8 hours
  • Development: 18 hours
Billing calculation:
RequirementQuotedMaxActualBillableBankedOverage
Design4.5h6h8hMIN(6, MAX(4.5, 8)) = 6h02h ⚠️
Development9h12h18hMIN(12, MAX(9, 18)) = 12h06h ⚠️
Total13.5h18h26h18h08h
Net: -8h overage Analysis:
  • Significantly under-estimated across the board
  • Gave away 8 hours of work
  • Action: Review estimation process, use larger t-shirt sizes for complex work

Tips for Improving Efficiency

Look at similar tasks you’ve delivered:
  • What size did you estimate?
  • How long did it actually take?
  • What unexpected issues came up?
Use historical data to calibrate estimates.
Spend 15 minutes clarifying requirements upfront to save hours of rework later:
  • What’s in scope and out of scope?
  • What are the success criteria?
  • Are there any edge cases?
  • What does “done” look like?
Don’t wait until end of day to log time:
  • Log time when switching tasks
  • Note what took longer than expected
  • This data improves future estimates
When you have overage, ask:
  • Was the estimate too optimistic?
  • Did scope expand mid-task?
  • Were there unexpected technical issues?
  • Could the approach have been better?
Learn from patterns to improve processes.
If a task is taking longer than expected:
  • Don’t wait until it’s done to raise it
  • Flag it when you hit 75% of the max estimate
  • Discuss whether to adjust scope or accept overage
Transparency helps manage expectations.
When you deliver efficiently:
  • Note what went well
  • Share with the team
  • Apply those practices to future work
Positive reinforcement of good practices.

Common Misconceptions

Reality: Overage can happen for legitimate reasons:
  • Genuinely underestimated complexity
  • Unexpected technical issues
  • Requirements weren’t clear
  • Scope expanded mid-task
The key is learning from it, not feeling bad about it.
Reality: Over-estimating has downsides:
  • Quotes become uncompetitive
  • Clients may question value
  • Encourages work to fill time (Parkinson’s Law)
The goal is accurate estimates that you can reasonably beat, not inflated ones.
Reality: Efficiency affects:
  • Client trust (are estimates reliable?)
  • Team morale (constant overage is demoralizing)
  • Capacity planning (inaccurate estimates mess up schedules)
  • Learning and improvement culture
It’s about more than just money.