Productivity is often discussed as if a purchase creates it automatically. In practice, a new system may initially add training, review, and coordination work. The return appears when a team changes the routine around the tool: fewer duplicate entries, clearer handoffs, stronger source material, or a shorter path from question to decision.
Choose a process with a visible baseline
A useful first target is a recurring process that has an owner and a measurable pain point. Record how long it takes, where it pauses, what errors recur, and what people do outside the official system to finish it. This baseline makes it possible to see whether an investment has removed effort or simply moved it.
Technology contributes to productivity when it improves a system of work, not when it merely changes the screen a person looks at.
Invest in complementary work
Skills, documentation, data quality, and manager attention are not optional extras. They are the conditions that let a tool be used consistently. A spreadsheet template may need common definitions. An AI assistant may need reviewed source material and a clear escalation path. A new customer platform may need a redesigned intake process.
Measure outcomes people recognise
Count what matters to the people doing the work: time to resolve a request, rework avoided, customer waiting time, or the percentage of a process completed correctly on the first pass. One metric should not hide a worse result elsewhere. Faster ticket closure, for example, is not a gain if it produces more repeat contacts.
Keep the learning loop open
Ask users where the new process creates friction and publish the decisions that follow. This makes adoption part of operations rather than a one-time change programme. It also gives leaders a better view of which investments deserve to expand.
Start with the process, not the purchase
A technology investment has a clearer chance of improving productivity when the work around it is already understood. Map the handoffs, waiting time, rework, and information gaps in one bounded process. Then ask whether software, training, clearer ownership, or a change in policy is the actual constraint. A new system can make an existing confusion faster; it cannot, by itself, establish the definitions or decisions that a team has never agreed on.
Baseline evidence need not be elaborate. A team can record the time to complete a recurring task, the number of handoffs, common error types, and the staff time needed to correct them. The baseline gives a future review something more useful than a vendor feature list. It also reveals when a simpler change such as a template, shared source, or better queue design would create most of the gain.
Give adoption an owner and a review date
Training, access, data quality, and local incentives determine whether a tool becomes part of work. Assign an owner for the affected process, provide a route for users to report friction, and set a date to compare the intended outcome with the baseline. Measure both benefits and displacement: time saved in one team can appear as checking work in another. A result that is mixed is still useful if it leads to a better scope or a decision to stop.
- Define the work outcome before choosing a product or model.
- Record the current task time, errors, handoffs, and review effort.
- Test with representative users, data, and accessibility needs.
- Track the work shifted to reviewers, support, and downstream teams.
- Revisit the decision against an agreed baseline and time frame.
Sources and further reading
See the OECD's work on AI and the future of work and the NIST AI Risk Management Framework. Our companion guide, designing an AI workflow people will use, begins with the handoff.