Set productivity targets using real performance data, not best-day averages. Use medians, variation, and service levels to create targets teams can reliably hit.
Most productivity targets fail for a simple reason: they’re set as aspirations, not as operational commitments grounded in how work actually flows. Teams then spend the quarter “chasing the number,” while leaders can’t tell whether misses are a performance issue, a demand issue, or a process issue.
A better approach is to set targets the same way you’d plan capacity: start with **real performance data**, translate it into **workable assumptions**, and build targets that account for **variation**. Here’s a practical way to do it.
1) Start with the right baseline: define the work and the unit
Before you analyze performance, make sure you’re measuring something stable.
**Clarify the work unit.** “Tickets closed” is not a unit if tickets vary wildly in effort. Many organizations find they need a tiered unit, such as:
- **Simple / standard / complex** cases - **Order lines** rather than “orders” - **Calls handled** segmented by call type - **Tasks completed** with clear entry/exit criteria
**Define “done.”** Targets fall apart when “done” differs by person or shift. Write down the minimum completion criteria (including documentation, QA steps, and customer follow-ups).
**Separate throughput from quality.** If you only target volume, quality becomes the hidden tax. Track at least one quality measure alongside productivity (rework rate, errors, audit pass rate, customer callbacks).
Operational tip: if you can’t define the unit in one sentence, your benchmark will be noisy and your target will be political.
2) Use performance data that reflects reality (not best days)
A common pattern is that leaders benchmark off the top performers or the best week. That creates targets that look “possible” but aren’t **repeatable**.
Instead, build your baseline from data that captures normal operating conditions.
**Choose a representative window.** Often 6–12 weeks is enough to include:
- Busy and slow days - Staffing fluctuations - Common exceptions (escalations, system issues, training time)
**Clean the data before you trust it.** Look for:
- **Outliers** (system outages, one-off projects) - **Mixed work types** (new work vs. rework vs. admin) - **Policy changes** (new QA rules, new scripts)
**Measure capacity in “productive time,” not paid time.** Paid hours include meetings, coaching, breaks, system friction, and coordination. If you set targets using paid hours, you’ll overestimate capacity and blame the team when math fails.
A practical method:
- Start with scheduled hours - Subtract known non-production time (meetings, training) - Estimate unavoidable operational time (handoffs, research, tooling) - What remains is **available production time**
This doesn’t need to be perfect; it needs to be honest.
3) Turn raw data into a target: median + variation + service level
Once you have a clean baseline, avoid using the average alone. Averages hide the spread—especially in queue-based work where complexity and arrivals vary.
Use the median as your “typical” performance
The **median** (50th percentile) is usually a more stable starting point than the mean. It reduces the impact of extreme days and gives you a “typical” outcome.
Then ask: what do you want the target to represent?
- **Commitment target**: what the team can hit most weeks without heroics - **Stretch target**: what’s possible with improvements and focus - **Capacity ceiling**: where quality or cycle time starts to break
Account for variation explicitly
Variation comes from:
- Work arriving unevenly - Case mix changing - New hires ramping - Dependencies (approvals, callbacks)
A practical approach is to set targets using **percentiles**:
- If you need high reliability, set the target near what the team achieves at the **60th–70th percentile** of days/weeks (not the 90th). - Use the **10th–20th percentile** as a “risk boundary” to trigger support actions (overtime, cross-training, backlog triage).
This makes targets operational: you’re not just setting a number—you’re defining how you’ll respond when conditions shift.
Tie the target to a service level, not just output
In queue-based work, output targets can be met while customers wait longer. Pair productivity with a flow metric:
- **Backlog age** (e.g., items older than X days) - **Cycle time** (start-to-finish) - **SLA attainment** (on-time completion)
If productivity rises but backlog age worsens, your “productivity” is likely being spent on easier work or rework.
4) Make targets actionable: segment by role, mix, and constraints
Even accurate benchmarks can fail if you apply one number to everyone.
Segment targets by role and work mix
Different roles face different constraints. For example:
- Specialists handle higher complexity - Senior staff get pulled into escalations - New hires spend more time learning and double-checking
Create target bands such as:
- **New hire (0–60 days)**: lower throughput, higher coaching time - **Proficient**: baseline target - **Expert / specialist**: different target tied to complex mix and mentoring
Build targets that include constraints you can’t wish away
Common constraints include:
- Approval bottlenecks - System latency - Limited upstream quality - Batch release schedules
If a constraint caps throughput, set the target to what the constraint allows—and set a separate improvement goal to remove the constraint.
Document assumptions and review them monthly
Targets become toxic when assumptions are invisible. Write down:
- Expected work mix - Expected staffing and coverage - Expected non-production time - Quality requirements
Then review monthly (or after major changes). This turns target-setting into a living management practice, not an annual argument.
Operational note: platforms like **ClearOps** help teams model queue-based work by connecting demand, capacity, and service levels—so targets stay tied to flow, not just output.
Conclusion: a practical checklist for realistic productivity targets
Realistic targets aren’t “lower.” They’re **defensible**, **repeatable**, and **linked to customer outcomes**. When set from actual performance data, they reduce noise in performance conversations and make improvement work clearer.
Use this checklist the next time you set or refresh targets:
- Define a stable **unit of work** and “done” criteria - Build a baseline from **representative weeks**, not best days - Convert paid hours to **available production time** - Use **median + percentiles** to reflect variation - Pair productivity with a **flow metric** (backlog age, cycle time, SLA) - Segment by **role, tenure, and work mix** - Document assumptions and **review monthly**
If you do those things, productivity targets stop being a scoreboard—and start becoming a reliable operating tool.