Time Savings — метрика реального сокращения человеческого труда благодаря AI. Она измеряет не «насколько быстро ответила модель», а сколько активного человеческого времени требовалось для выполнения сопоставимой задачи до AI и сколько требуется после внедрения AI с учётом prompting, review, corrections, rework, escalation and recovery.
№85 Adoption says how many people use AI. №86 Coverage says how much work AI handles. №87 Time Savings says how much human active work is removed. №90 Cost per Operation converts system operation into monetary cost. №88 Acceptance and Evals protect against “saving time” by lowering quality.
Need stable task taxonomy, baseline method, task identity, human work phases, review/rework measurement, comparable cohorts and quality outcome. Savings claims without baseline or with mismatched task difficulty are weak.
CONTROL: baseline definition, active-time rules, exclusions, sampling/measurement methodology. DATA: task phase timestamps, user active events, review/rework, surveys/time studies. RUNTIME: minimal instrumentation. OFFLINE: baseline estimation, matching, cohort analysis, uncertainty and aggregation.
Failure = comparing model latency with human baseline, ignoring review/rework, assuming saved minutes from self-report only, counting waiting as labor, comparing different task complexity, or multiplying a tiny pilot result across all company tasks without eligibility/coverage checks.
Time Savings does not prove cost savings, headcount reduction or business value. Saved minutes may be reinvested, absorbed by demand, or fail to convert into capacity. It owns human active-time delta per comparable unit of work.
Net Human Time Savings per Task = baseline_human_active_minutes − post_AI_human_active_minutes where post_AI includes: prompt / instruction time + review time + edit/correction time + human decision/approval time + recovery from AI failure + manual rework caused by AI
Minutes actually spent by a person on task-related work.
Task start → completion including waits, queues, AI processing and handoffs.
Model/tool/browser/workflow runtime; affects latency and cost, not necessarily human labor.
Example: Before AI: human active = 45 min elapsed = 50 min After AI: human active = 12 min AI/background wait = 8 min elapsed = 24 min Human time savings: 33 min Cycle-time savings: 26 min Machine time: 8 min Three different metrics.
Time Savings Rate = baseline_human_active − post_AI_human_active ------------------------ baseline_human_active × 100% Example: baseline = 40 min post-AI = 16 min Savings = 24 min Savings Rate = 60%
Time AI appears to replace before overhead.
Gross saving minus prompting, review, correction, coordination and recovery.
Original manual task: 60 min AI generation replaces: 45 min But adds: 5 min prompting 12 min review 8 min corrections Gross saving: 45 min Net post-AI human time: 15 + 5 + 12 + 8 = 40 min Net saving: 60 − 40 = 20 min Not 45.
Strong practical baseline when tasks are repeatable.
Good if process already tracked human active work.
Controls for seasonality and workload changes.
Useful early, but label separately and replace with measured baseline.
BAD: Manual cohort: complex research reports AI cohort: simple summaries Result: “AI saves 75%” This is confounded by task mix. BETTER: match/stratify by: task_type complexity risk_class language input size user experience product/version period
Manual minutes: 10, 12, 11, 9, 180 Mean = 44.4 min Median = 11 min AI minutes: 6, 6, 7, 5, 60 Mean = 16.8 min Median = 6 min Mean saving: 27.6 min Median saving: 5 min Both useful. They answer different questions.
Collect inputs, brief, context, source files.
Writing, search, coding, analysis, calculation.
Read, validate, compare, inspect evidence.
Edits, fixes, reruns, clarification.
Approve, publish, submit, execute action.
Before AI: create = 35 min review = 5 min total = 40 min After AI: prompt = 3 min create by AI = 0 human min review = 18 min edit = 7 min total = 28 min Net savings: 12 min = 30% AI removed creation effort but increased review burden. This is still positive, but very different from “AI created it in 20 seconds.”
Prompt + quick check only.
Formatting, wording, light corrections.
Human reconstructs substantial portion of output.
AI attempt plus full manual work can cost more time than baseline.
baseline human active: 20 min post-AI: prompt 3 review 8 correction 12 recovery 4 total = 27 min Time Savings: 20 − 27 = −7 min Savings Rate: −35% Do not clamp to zero. Negative values are valuable: they show where AI creates additional work.
| Method | Strength | Weakness |
|---|---|---|
| Instrumented active-time tracking | Detailed phase data, scalable | Hard to infer true attention; privacy/UX concerns |
| Time-and-motion study | High-quality measured sample | Expensive and limited sample |
| Matched control cohort | Good causal comparison | Needs comparable work allocation |
| Task timestamps + active interaction heuristics | Practical at scale | May over/under-estimate inactive periods |
| Self-reported time | Cheap, captures hidden work | Recall and desirability bias |
| Expert estimate | Fast for early opportunity sizing | Weak evidence; not a final ROI metric |
Possible UI heuristic: active if: interaction event AND idle gap < 90 seconds phase examples: prompt_edit source_review output_review manual_edit approval recovery Do NOT assume: browser tab open = active labor Do NOT capture: unnecessary raw content keystroke surveillance unrelated user activity
Survey: “How long would this task take without AI?” “How long did you actively spend with AI?” Then compare on sampled tasks with measured time study. If survey systematically says: 40% more savings than observed, apply: separate reporting or calibration model. Never silently mix measured and estimated savings.
| Acceptance class | Typical time effect |
|---|---|
| Accepted as-is | Largest potential savings; still includes review. |
| Minor edit | Usually positive savings. |
| Major edit | Savings uncertain; depends on how much original work remains useful. |
| Rejected | Often zero or negative savings because AI attempt is sunk overhead. |
LOW: baseline 5 min post-AI 2 min save 3 min = 60% MEDIUM: baseline 30 min post-AI 15 min save 15 min = 50% HIGH: baseline 180 min post-AI 120 min save 60 min = 33% Absolute savings: HIGH is largest. Relative savings: LOW is largest. Both matter.
AI may save more time but require more verification guidance.
AI may save less creation time but accelerate search/repetition.
Prompt/review workflow may reduce post-AI human time relative to new users.
Total Net Human Hours Saved = Σ over successful eligible AI tasks: max? NO — use signed task saving (baseline_minutes_matched − post_AI_human_minutes) ÷ 60 Important: keep negative savings. failed/rejected AI tasks must remain in aggregate.
Expected net saving / AI attempt = P(as_is) × saving_as_is + P(minor_edit) × saving_minor + P(major_edit) × saving_major + P(rejected) × saving_rejected + P(failure) × saving_failure Example: 0.50 × 30 min +0.25 × 20 +0.15 × 5 +0.07 × (-10) +0.03 × (-15) = 19.6 min expected saving / attempt
Measured per-task human active-time delta.
Can person/team perform more valuable work with saved time?
Higher throughput, faster SLA, reduced overtime, lower external spend, more output.
Team before AI: 8 hours/day 12 cases/day AI saves: 2 human hours/day Possible realized outcomes: A. Throughput: 12 → 16 cases/day B. Faster SLA: same 12 cases, shorter response time C. Quality: same volume/time, more review depth D. Capacity: saved time moved to other high-value work E. No realized value: time fragmented / not reusable
Raw task savings: 20 tasks × 5 min = 100 min But if savings are: scattered interrupted impossible to schedule consumed by context switching usable capacity may be lower. Optional planning model: realizable_capacity = raw_saved_time × realization_factor Example: 100 min × 0.65 = 65 usable min CAUTION: realization_factor must be empirical, not invented to force ROI.
Cycle Time Savings = baseline_elapsed_time − post_AI_elapsed_time Useful for: customer response document turnaround incident resolution approval SLA research delivery But: shorter cycle time can occur with zero human-hour saving and vice versa.
Monthly potential human hours saved = eligible task volume × accepted/successful coverage × average net human minutes saved per task ÷ 60 Example: 100,000 eligible tasks × 45% accepted coverage × 8 min net savings ÷ 60 = 6,000 human hours/month
AI works well for users who use it; onboarding/integration/discovery may block scale.
AI may be popular but not materially reduce human work.
Economic value per task ≈ human_minutes_saved × loaded_human_cost_per_minute − AI_variable_cost − incremental_review/recovery_cost Example: 15 min saved × $0.80/min = $12.00 labor capacity value AI direct cost: $0.60 Net gross capacity value: $11.40/task But: this is not necessarily cash savings or headcount reduction.
| Pattern | Interpretation |
|---|---|
| Time Savings ↑, Acceptance stable/high | Likely real productivity gain. |
| Time Savings ↑, severe errors ↑ | Unsafe speed-up; review may be insufficient. |
| Time Savings ↓, Acceptance ↑ | More human review may improve quality; decide whether trade-off is worth it. |
| Time Savings ↑, Coverage ↓ | System may be routing only easiest tasks to AI. |
| Time Savings ↑, Cost/Operation ↑↑ | Faster labor but expensive AI; evaluate total economics. |
Full system: RAG + reranker + critic Ablation: remove critic Result: Full: human review = 8 min AI cost = $0.80 No critic: human review = 12 min AI cost = $0.45 Critic saves: 4 human minutes/task But costs: +$0.35/task Decision: compare value of 4 min with additional cost and quality delta.
Always show number of matched/measured tasks.
Time is usually skewed.
Especially for extrapolated company-level savings.
Report both: Per-task: median savings p25 / p75 savings rate Portfolio: total signed hours saved by use case Why: rare 4-hour tasks can produce more total value than thousands of 30-second tasks.
Store task phase effort rather than surveillance logs.
Do not collect unnecessary detailed behavior.
Use-case/team cohorts over individual rankings.
Align with №76 Privacy & Governance.
{
"task_id":"TASK-...",
"task_type":"draft_marketing_post",
"complexity":"medium",
"cohort":"marketing_team_a",
"baseline":{
"method":"matched_control",
"human_active_seconds":2400,
"baseline_version":"v2"
},
"post_ai":{
"prompt_seconds":180,
"review_seconds":420,
"edit_seconds":300,
"approval_seconds":60,
"recovery_seconds":0,
"total_human_active_seconds":960
},
"outcome":{
"accepted":"minor_edit",
"success":true
},
"product_version":"2026.09.1"
}
time_savings_task( task_id task_type complexity cohort occurred_at baseline_method baseline_active_seconds baseline_version prompt_seconds review_seconds edit_seconds approval_seconds recovery_seconds post_ai_active_seconds elapsed_seconds success acceptance_class product_version )
SELECT
task_type,
percentile_cont(0.5) WITHIN GROUP (
ORDER BY
baseline_active_seconds
- post_ai_active_seconds
) AS median_seconds_saved,
AVG(
baseline_active_seconds
- post_ai_active_seconds
) AS mean_seconds_saved,
SUM(
baseline_active_seconds
- post_ai_active_seconds
) / 3600.0 AS total_hours_saved
FROM time_savings_task
WHERE baseline_active_seconds IS NOT NULL
GROUP BY task_type;
% measured AI tasks with valid baseline estimate.
Missing edit/recovery time biases savings upward.
Manual and AI task mix aligned/stratified.
Never silently mix instrumented and self-reported baselines.
LOW / NEGATIVE TIME SAVINGS ↓ Is baseline valid? no → fix measurement yes ↓ Prompt/setup too long? yes → UX/context automation no ↓ Review too long? yes → improve confidence/evidence/UI no ↓ Major edits common? yes → quality/prompt/RAG/model issue no ↓ Failures/retries frequent? yes → resilience/tool quality no ↓ Task type is inherently human judgment? yes → AI may support but not save much active time no ↓ AI only saves tiny fragmented intervals? yes → realization issue no ↓ Check task mix / cohort / baseline drift
Typical per-task labor reduction.
Normalized relative reduction.
Portfolio-level realized task labor delta.
Post-AI quality-control burden.
Edit/correction/recovery burden.
% tasks where AI takes more human time than baseline.
% tasks with valid comparable baseline.
Separate elapsed-time improvement.
DATA 1. task_id 2. task_type 3. complexity 4. baseline human active minutes 5. baseline method/version 6. prompt/setup minutes 7. review minutes 8. edit/rework minutes 9. recovery minutes 10. task outcome / acceptance 11. product version MVP METRICS 1. median net minutes saved 2. median savings rate 3. total signed hours saved 4. review time 5. rework time 6. negative-savings share 7. time savings by task type 8. time savings by acceptance class GUARDRAILS 1. Acceptance Rate 2. severe error rate 3. Cost per Successful Operation 4. Coverage
| Question | Status |
|---|---|
| Is the baseline measured or explicitly labeled estimated? | Required |
| Are compared tasks similar in type/complexity? | Required |
| Are prompt, review, edit and recovery included? | Required |
| Are negative-saving tasks included? | Required |
| Are elapsed time and human active time separated? | Required |
| Is sample size shown? | Required |
| Are median/distribution shown beside mean? | Recommended |
| Is quality/acceptance paired as a guardrail? | Required |
| Is organizational “hours saved” based on actual coverage? | Required |
| Are “hours saved” kept separate from “cash saved”? | Required |
You are designing Time Savings analytics for an AI product.
1. Define the real task unit.
2. Separate:
human active time,
elapsed/cycle time,
machine processing time.
3. Define a valid baseline:
measured historical,
matched control,
direct time study
or explicitly labeled estimate.
4. Match/stratify tasks by:
task type,
complexity,
risk,
user maturity,
language/input size where relevant.
5. Post-AI human time must include:
prompting/setup,
review,
editing/rework,
approval,
recovery from failures.
6. Compute:
absolute net minutes saved,
savings rate,
total signed hours saved.
7. Keep negative values.
8. Report:
median,
mean,
p75/p90,
sample size.
9. Segment by:
task type,
complexity,
acceptance class,
cohort,
product version.
10. Pair with:
Acceptance Rate,
Coverage,
Cost per Operation,
quality/risk guardrails.
11. Do not equate:
model latency with human time,
task hours saved with cash savings.
12. Official metrics must be calculated deterministically
in analytics SQL/code.
13. LLM may explain patterns
or propose measurement design,
but not fabricate missing baselines.
| Question | Answer |
|---|---|
| Separate component? | N/A. Time Savings is a governed metric; event/time-study analytics implement it. |
| Minimum 80% value? | Task-level baseline + post-AI human phases + net signed delta + acceptance class + cohort/complexity slices. |
| When overkill? | Very early prototype before a comparable manual process exists; use opportunity estimates but label them as estimates. |
| Trigger? | “Does AI actually save people time?”, “Where does review erase the benefit?”, “How many hours are realistically released?”. |
| How to measure uplift? | Matched pre/post or control task samples, quality guardrails, and coverage-weighted aggregation. |
| Can rules/code replace LLM? | Yes. Calculation and matching logic should be deterministic/statistical. LLM may classify task phases or explain anomalies if validated. |
REAL TASK ↓ DEFINE COMPARABLE BASELINE BEFORE AI: prep create review edit approve sum = BASELINE HUMAN ACTIVE TIME ↓ AFTER AI: prompt/setup + human review + human edits + approval + recovery/rework sum = POST-AI HUMAN ACTIVE TIME ↓ NET SAVING baseline active − post-AI active can be: positive zero negative ══════════════════════════════════ SEPARATE: HUMAN ACTIVE TIME labor ELAPSED / CYCLE TIME calendar duration MACHINE TIME AI/tool compute ══════════════════════════════════ BREAK DOWN BY: task type complexity acceptance class user maturity risk class product version ══════════════════════════════════ PAIR WITH: ACCEPTANCE was result useful? COVERAGE how much work gets this saving? COST / OPERATION what does AI cost? QUALITY / RISK is speed safe? ══════════════════════════════════ ORGANIZATIONAL IMPACT: total signed task savings × real coverage → released human capacity BUT: RELEASED CAPACITY IS NOT AUTOMATICALLY CASH SAVINGS. It may become: more throughput faster SLA higher quality new work less overtime or no realized value if fragmented / unused. ══════════════════════════════════ THE CENTRAL QUESTION IS NOT: “HOW FAST DID THE MODEL RESPOND?” IT IS: “FOR THE SAME REAL TASK AT THE SAME QUALITY BAR, HOW MUCH LESS ACTIVE HUMAN WORK WAS REQUIRED AFTER AI — INCLUDING REVIEW, CORRECTION AND FAILURE RECOVERY?” THAT IS TIME SAVINGS.
A. Related ECC ideas. Context-as-cache, scoped memory, lifecycle hooks, selective capabilities, feature flags, deterministic enforcement, provider-neutral adapters and eval-gated learning are applied only where relevant to №87 Time Savings.
B–E. Existing boundary and placement. The existing conceptual boundary, class METRIC, default N/A and owner Evals / Analytics / Management remain authoritative. Runtime/control/data/offline placement is unchanged; durable state stays outside model context.
F–H. Hooks and contracts. Use bounded PRE_MODEL/POST_MODEL, PRE_TOOL/POST_TOOL, CHECKPOINT and TASK_COMPLETED events as applicable. Illustrative fields and canonical contracts are defined in NEW_CONTRACTS_SPEC.md; no universal schema is implied.
I–J. Security and evaluation. Host-side schema, permission, secret, budget, idempotency and audit checks take precedence over LLM output. Optional mechanisms require a feature flag and WITH/WITHOUT ablation; measure quality, acceptance, correction, latency, cost, escalations and severe errors.
K–L. Task profiles and cross-references. A TaskProfile selects the relevant skill, tool/context slice, memory scope and enforcement profile independently from FAST/STANDARD/DEEP. See cross-reference map, hook spec and ablation plan. Provider adapters remain outside the core.