Implementation worksheet · 6 min read
A Campaign Operations Time-Study Protocol
Split each campaign into stages with start and stop evidence you can observe (brief approved, audience saved, draft submitted, QA passed, approved, scheduled, report delivered) and record two numbers per stage: touch time, when someone is working, and elapsed time, which includes waiting. Time a baseline of the same campaign types before the change and after it, count rework loops and abandoned campaigns, and report medians with their spread for each campaign type. Because this is a before-and-after comparison, keep a log of what else changed, and keep timing past the first weeks, when people are still learning the new way of working. Don't convert minutes into money without saying where the time went.
Scope: a lifecycle operations lead measuring the effort it takes to run campaigns, before and after a change such as a new platform, an AI drafting agent or a redesigned approval step. Starting state: estimates like 'a campaign takes us about a week'. Boundary: operator time spent producing and reporting campaigns, not how the messages perform. Intended outcome: stage-level medians that show where the time goes, so the next fix targets the real bottleneck.
Put it into practice
1. Fix the stages and their start and stop evidence
Use events your tools already record where you can: ticket created, segment saved, draft submitted, approval clicked, send scheduled. Recalled durations ('about two hours') are the weakest input available, because nobody can check them later.
2. Record touch time separately from elapsed time
Elapsed time comes from system timestamps. Touch time needs a lightweight log: a start and a stop for each work session. Self-logged time is approximate, so keep the logging method identical before and after; a change in method shows up as a change in speed.
3. Sample by campaign type, not overall
A one-off broadcast, an edit to a live journey and a new multi-channel journey take different amounts of work. If the after period happens to contain more broadcasts, the overall average falls with no change in speed. Report each type separately. As a working rule of thumb, not a statistical threshold, list individual durations instead of a median when a type has fewer than ten campaigns in a period.
4. Count rework and abandonment
Record each time a campaign goes back a stage (a QA rejection, a legal change, a rebuilt audience) and every campaign started and then cancelled. A drafting step that gets faster while QA rejections double isn't faster, and a period that looks quick because the hard campaigns were abandoned isn't either.
5. Keep timing past the learning period
The first weeks of a new process are often slower while people learn it, and people who know they are being timed may work differently. Keep timing for several weeks after the change and compare the later weeks with the baseline, rather than reporting the first week in either direction.
6. Report medians, spread and n for each stage
Medians resist the one campaign that sat in approval for two weeks; the interquartile range shows whether a typical campaign is predictable. Include n in every cell, plus the change log. If you convert time to cost, state what the freed hours were used for, or report hours only.
7. Worked example (illustrative, synthetic numbers)
Broadcasts, six weeks before and six weeks after an AI drafting assistant was introduced (n = 14 and 15). Median drafting touch time fell from 95 to 40 minutes. QA touch time rose from 30 to 45 minutes, and rework loops from 0.4 to 0.9 per campaign. Median approval wait stayed at 26 to 27 hours. Brief-to-send elapsed time moved from 3.1 to 2.9 days. Decision: drafting improved, but approval wait sets the pace, so the next change targets the approval queue. New journeys (n = 5 and 4) were listed individually.
Time-study log for broadcasts (illustrative values)
Copy this structure into your review document and record your observed result for each row.
| Stage | Start evidence | Stop evidence | Measure | Before → after |
|---|---|---|---|---|
| Brief | Brief ticket created | Brief approved | Median elapsed time | 1.0 → 1.0 days |
| Audience | Segment draft saved | Segment count reviewed | Median touch time | 35 → 30 min |
| Drafting | Draft started | Draft submitted to QA | Median touch time | 95 → 40 min |
| QA | QA started | QA passed | Median touch time; mean rework loops | 30 min, 0.4 loops → 45 min, 0.9 loops |
| Approval | Submitted for approval | Approved | Median elapsed wait | 26 → 27 hours |
| Scheduling | Approved | Scheduled or sent | Median touch time | 15 → 15 min |
| Reporting | Send completed | Report delivered | Median touch time | 60 → 55 min |
| Abandoned | Campaign started | Campaign cancelled | Count per six weeks | 2 → 3 |
| Brief to send | Brief ticket created | Send started | Median elapsed time | 3.1 → 2.9 days |
A failure worth checking
The demo stopwatch. A pilot reports that campaigns now take 40 minutes instead of 'about a week'. The 40 minutes was touch time for one broadcast, built by the most practiced person while being timed; the week was elapsed time recalled from memory, including approval waits the pilot never touched. Both numbers may be true, and they measure different things. Verification: rebuild the baseline from the system timestamps of past campaigns of the same type, compare touch time with touch time and elapsed time with elapsed time, and repeat the measurement once the first few weeks have passed.
Common questions
Can we turn the minutes saved into a cost saving?
Only if the freed time went somewhere you can name. Multiplying hours by salary assumes they became other output. Report hours freed, and separately what the team did with them, such as more tests run or a backlog cleared.
Should we time the people or the tools?
Both: system timestamps for elapsed time and a short self-log for touch time. Treat the self-log as approximate and keep its method unchanged between periods, so that whatever bias it has is the same on both sides.
Basis and scope
This is a proposed implementation method using illustrative examples, not a measured benchmark or a customer case study. Prepared with AI assistance. Validate product-specific behavior against current documentation and your own test environment.