Draft quarterly OKRs that fail the 'sandbagged target' test before your manager does

Draft quarterly OKRs for the team/function below, and specifically stress-test them for being sandbagged — targets set comfortably low so they're easy to hit — before I take them into review.

TEAM OR FUNCTION
Customer Support, 12-person team.

OBJECTIVE THEME
Reduce how long customers wait for a resolved answer.

CURRENT BASELINE METRIC
Average resolution time is currently 9.5 hours; first-response time is 2 hours.

STRETCH VS. COMMITTED INTENT
Want one committed KR we're confident we'll hit, and one real stretch KR even if there's a real chance we miss it.

DEPENDENCY ON ANOTHER TEAM
Faster resolution depends partly on Engineering shipping a promised macro-automation feature, which isn't fully in Support's control.

Write one objective — a qualitative statement of direction, not a number — and two to three key results under it, each a specific measurable target with a number and a deadline. For each key result, check it explicitly against the current baseline: if the target is barely above the baseline given the quarter's timeframe, flag it as a likely sandbagged target rather than presenting it as ambitious, and propose a genuinely stretch alternative alongside it so I can see both. Respect the stated stretch-vs-committed intent — a key result explicitly meant to be a safe committed target should be labeled as such rather than dressed up in stretch language, and a key result meant to be a real stretch should be allowed to carry real risk of missing, since OKRs that are all committed and none stretch defeat the purpose of the framework. Where a key result depends on another team delivering something first, state that dependency explicitly next to the key result and flag the risk that hitting this KR is partly outside this team's control — an OKR that silently assumes another team's cooperation sets the owning team up to be blamed for someone else's miss.

WHAT NOT TO DO
Do not write key results as activities ('launch the new dashboard') instead of outcomes ('reduce average resolution time to under 4 hours') — an activity can be completed without moving anything that matters. Do not inflate the objective statement with vague ambition language that isn't backed by an actual key result underneath it.

OUTPUT FORMAT
1. Objective (one sentence, direction not number).
2. Two to three key results, each numbered, with target, deadline, and a stretch/committed label.
3. For any KR flagged as likely sandbagged, the stretch alternative shown alongside it.
4. Dependency flags for any KR partly outside this team's control.