Design Roles Around Tasks, Not Job Titles

A job title tells you who works in a team. It doesn't tell you which parts of their day AI can help with, where an error would matter, or who must make the final decision. To redesign work, follow a real case and split it into tasks. Give each task an owner, a permitted system action, and a route for exceptions before you change a job description.

Break the job into completed tasks

Ask two people with the same title to walk through recent cases. You may find that a procurement analyst spends part of the week chasing documents, part checking supplier details, and part deciding whether an exception needs a manager. Those activities call for different data, judgement, and authority. A single label such as “procurement analyst” hides that difference.

For each case, mark five kinds of work: gathering facts, drafting an output, judging an exception, approving a decision, and carrying out an action. Record volume, active time, error rate, and the consequence of a wrong result for each task. A task ends when the next person or system has something they can act on. Count the time spent correcting a bad draft in the task that produced it.

The ILO's 2025 study of generative AI and work assesses exposure at the task level and finds that changes within jobs are more likely than full replacement for many occupations. Exposure is a measure of potential, not a staffing forecast for your company. You still need to observe your own work and test a specific system.

Map a supplier onboarding case

Follow a new supplier from request to approved payment record. Ask the team to show a routine case, a supplier with missing documents, and a case involving a bank-detail change. Those three paths reveal why a fluent summary cannot stand in for a complete workflow.

• Gather facts: Software can collect submitted forms, approved registry data, and existing supplier records, with a link to each source. A procurement coordinator owns the case and checks gaps or conflicting identities. The system should flag a missing document rather than invent its contents.
• Draft: An AI assistant can assemble a proposed supplier profile and a short note explaining discrepancies. The coordinator checks names, tax details, and cited records. The draft is a work product for review, not approval.
• Judge: A procurement or risk specialist decides whether an exception fits policy. They need the original records, the reason for the flag, and a way to reject the proposed answer. The system may recommend a route but cannot create a new policy by analogy.
• Approve: The authorised manager approves the supplier under the company's delegation rules. A bank-detail change may need separate verification and a second approver. Store who approved which version, when, and on what evidence.
• Act: After approval, an integration can create or update the ERP record within scoped permissions. It should confirm the write succeeded and alert an owner if the ERP rejects or duplicates it. Finance reconciles the final record before payments rely on it.

These tasks cross procurement, risk, and finance even if one employee handles several of them in a small firm. The task map keeps the handoffs clear as the team grows or changes tools.

Set authority at each handoff

Write an authority rule beside every task: what the system may read, what it may suggest, what it may write, and when it must stop. A lookup of a public registration number has a different consequence from changing the bank account that will receive a payment. Review frequency should follow the consequence of an error and the quality observed in tests, not a blanket instruction to keep a person “in the loop.”

Give the human reviewer enough context to make a real decision. If the screen shows only the AI's conclusion, the reviewer may approve it without seeing the missing evidence. Show the source records, the proposed change, and the reason the case reached them. Measure rejected drafts and missed exceptions. A person who merely clicks approve on every case isn't an effective control.

NIST's AI Risk Management Framework calls for defined human and AI responsibilities and documented oversight. Its human-AI interaction guidance describes several configurations, from a human using AI as another opinion to a system that defers a decision to an expert. Choose the configuration for the task and record it in the process.

Change the human role deliberately

When software takes over some gathering and drafting, staff may spend more time on exceptions, customer or supplier conversations, and final decisions. Check whether the team has enough experience and time for that work. A manager who inherits every flagged case can become the new bottleneck. Set a daily review capacity and a route for cases that exceed it.

Protect the path by which newer staff learn the job. If they no longer prepare routine cases, give them supervised exposure to source records, policy decisions, and the reasons reviewers reject AI output. Otherwise the organisation may lose the people who can judge difficult cases later. Ask staff which steps currently teach them how the business works before removing those steps.

Don't turn estimated minutes saved into a headcount plan without measuring completed work. A lower drafting time can disappear into checking, exception handling, and higher case volume. State whether the aim is shorter lead time, better quality, capacity for growth, or a budget reduction. Each outcome needs a different measure and a management decision.

Test the new design on real work

Choose a limited group of cases and agree on the old process's baseline. Track time to an approved supplier, staff handling and review minutes, rejected or corrected records, bank-detail errors, and cases sent back for missing evidence. Keep routine and high-risk cases separate. Compare the full outcome after the ERP update, not the speed of the first AI draft.

During the test, log every handoff that stalls and every task that falls between owners. If reviewers cannot keep up, reduce the system's scope or change the review design. If a source record is stale, fix the source or require a manual check. Microsoft’s guidance on agent roles and decision rights recommends assigning concrete tasks, autonomy limits, and one accountable role per task. Use the test to check whether those assignments work outside the process diagram.

Write a role card that people can use

Update each affected role with the tasks it now owns, the decisions it may make, the evidence it must review, the system permissions it can grant, and the escalation path. Write a matching system card with its allowed inputs, outputs, actions, limits, and person responsible for fixing it. A job title can stay the same while these duties change; staff need to know what changed in their actual day.

Review the cards after the first month of live use. Check case quality and workload with the people who perform and approve the work, then adjust authority or staffing where the evidence points. That gives the organisation a way to redesign a role through observed tasks instead of guessing from a title.