Start with the work, not the job title
A job is a bundle of activities, not a single unit of work. Two people with the same title may spend their days differently, while people in different roles may share tasks such as scheduling, checking records, or answering routine questions. That is why a prediction that a job will be “automated” is often less useful than a close look at what its workers actually do.
A task map breaks a role into recognizable activities and records how each one gets done. It can help a team see where a tool might save effort, where it might create new checking work, and where human interaction remains central. The purpose is not to label workers as replaceable. It is to make proposed changes specific enough to discuss and test.
Build a map with the people doing the work
Begin with a defined workflow, such as handling a customer request from arrival to resolution. Ask the people involved to list its tasks in order, including informal steps that may be missing from a procedure. For each task, note its inputs, output, tools, handoffs, and what counts as a good result. Record exceptions as well as the usual path: unusual cases often reveal why a seemingly simple activity requires experience.
Next, describe each task along a few practical dimensions. Is it frequent or occasional? Are its inputs consistent or messy? Does it require interpreting context, persuading someone, protecting sensitive information, or noticing when the usual rule does not fit? What happens if an answer is wrong, and who catches the error? Rough labels are enough at first. A map should support conversation, not pretend to measure every part of a job precisely.
Make room for work that is easy to overlook. A receptionist, for example, may enter appointments into a system, but may also calm a confused visitor, spot a language barrier, and coordinate with colleagues when the schedule fails. A map built only from software records would capture the entries and miss much of the service.
Separate possible tool use from a good decision
Once the tasks are visible, ask where a tool could assist, where it could perform a step under review, and where it should not be used. Repetitive, well-defined tasks may be easier to test than tasks with ambiguous inputs or serious consequences. But technical possibility is only one consideration. A tool can produce a fast draft that takes longer to verify than writing the answer directly.
Imagine a small housing-services team that receives repair requests. A tool might sort incoming messages into categories and prepare a summary for staff. That could reduce copying and searching. It might also misread an urgent safety concern or fail to capture the caller’s circumstances. The team could therefore test sorting while keeping a person responsible for reviewing urgent requests and contacting residents. In this example, automation changes part of the intake process; it does not remove the need for judgment, communication, or accountability.
For every proposed use, identify the person who can correct the tool, the route for escalating uncertain cases, and the information needed to check its output. If those safeguards are unclear, the task may not be ready for automation.
Map the changes around the task
A task rarely changes in isolation. If software drafts responses, someone may need to review them, maintain approved information, handle exceptions, and explain decisions to customers. Those activities take time and may require different skills. Mark the likely new tasks beside the ones a tool might reduce, then trace how the change affects colleagues before and after each handoff.
This also makes training more concrete. “Learn automation” is a vague goal; learning to check a generated summary against an original request is a teachable practice. Workers may need time to understand a tool’s limits, report recurring errors, and adjust a workflow. Managers should ask whether the revised workload allows for those steps rather than assuming that faster output automatically means spare capacity.
Test, review, and keep the map open to revision
Choose a narrow pilot and decide in advance what success would look like. Compare the old and proposed workflows using measures the team can observe, such as time spent on corrections, missed exceptions, customer clarity, and worker ability to resolve problems. Invite feedback from people affected by the service, particularly when a new process may make it harder for someone to ask for help or access a human response.
Return to the map after the pilot. Some tasks may have shifted rather than disappeared; others may prove more complex than expected. Keep notes on what changed and why, and let workers challenge an inaccurate description of their work. A useful task map is a living account of how work gets done. Its value lies less in predicting the fate of a job than in helping people make deliberate, accountable choices about the tasks within it.
