The manager sees a faster way to write replies. The coordinator sees another screen to check, a queue of drafts to repair, and a question nobody has answered: if this saves time, what happens to my job?
Both are looking at the same proposed tool. They are looking at different parts of the work.
A useful adoption plan deals with the whole change: tasks, workload, information, responsibility, skills, and consequences. Your work product is a small pilot agreement, a feedback register, and a scorecard that shows whether the work improves.
This chapter uses constructed Mesa examples. No staff consultation, training session, pilot, survey, or workplace change has actually occurred.
Start by listening to the people who handle the exceptions
Ask staff to walk through a recent task. Where did they search for information? What did they have to correct? Who made the final decision? What happens when the normal process does not apply?
Include experienced workers, newcomers, reviewers, and people on different shifts when those perspectives matter. Someone who handles only unusual cases may see risks that disappear from an average response-time report.
The OECD reports that, in its surveys of manufacturing and finance employers and workers across seven countries, training and worker consultation were associated with better worker outcomes. That is an association in the studied settings, not proof that any particular consultation causes success. See the OECD's AI and work overview.
Use the conversation to change the plan. If employees identify duplicate entry or a missing policy, assign a resolution. Asking for input and then hiding its disposition gives people little reason to keep contributing.
Describe a problem people recognize
“Become an AI-powered company” does not tell a coordinator what will happen on Monday. “Test whether reviewed drafts reduce the effort needed for routine policy questions” is clearer.
For Mesa's proposed pilot, keep the task narrow: draft answers to routine service-policy questions from the approved source packet. Exclude booking confirmation, discounts, refunds, sensitive complaints, and questions without adequate sources. A reviewer remains responsible for the answer before any customer use.
That boundary makes it possible to learn. A pilot that changes the tool, policy, staffing, incentives, and customer channel all at once makes a good or bad outcome harder to explain.
Write down the current alternative. Here it is the existing manual process using the same approved policy. If the manual process is poorly documented, improve the reference first. Otherwise, the pilot may only demonstrate the value of finally writing down the rules.
Write an agreement people can question
A pilot agreement should answer practical questions before the first real task enters the system.
| Question | What the agreement should specify |
|---|---|
| What changes? | The task, eligible cases, and proposed period |
| Who owns it? | Sponsor, workflow owner, reviewer, and support contact |
| What stays with a person? | Decisions and actions requiring review or approval |
| What data is used? | Approved inputs, access, retention, and permitted purposes |
| What will be measured? | Quality, complete effort, exceptions, and staff feedback |
| What support is available? | Training time, accessible materials, and help |
| When do we pause? | Concrete failures that trigger fallback and review |
| Who decides what happens next? | Decision-maker, evidence, and review date |
Do not fill unresolved fields with reassuring guesses. If nobody has agreed to provide backup review, mark it unassigned and resolve it before the workflow depends on it.
Mesa's earlier DELAY-SOP-01 remains a draft, and its backup coverage is unresolved. A new AI pilot does not silently approve that old procedure or supply the missing person.
Be honest about jobs, pay, and monitoring
People deserve to know the actual proposal. Explain which tasks may change, what decisions have been made, and what has not been decided. Do not promise that jobs or pay can never change if the organization has made no such commitment.
If the stated purpose is workflow improvement, do not quietly repurpose practice logs to create employee rankings. Any proposed employment use deserves its own review, evidence, communication, and applicable process. Chapter 29 explains why ordinary AI training does not authorize consequential employment decisions.
Say what the system records and who can see it. Distinguish approved operational records from optional feedback. A survey described as anonymous must actually be designed to protect anonymity; a small team or free-text comment may make the speaker recognizable. Promise confidentiality only to the extent the process can deliver it.
Use plain language and invite questions through more than one route. Some workers will speak in a group; others may prefer a private conversation or written note. Check applicable consultation or representation requirements before introducing the real change. A sample agreement is a planning tool, not a substitute for those obligations.
Budget for the work the tool creates
Drafting may get faster while reviewing gets harder. Someone must maintain policy files, inspect unusual cases, answer staff questions, and handle tool failures. If that work has no owner or allotted time, it lands on whoever is most conscientious.
Assign training and review capacity before increasing volume. Remove an old step only after confirming what purpose it served. Keeping every old check and adding every new check can make a pilot slower even when each individual feature works.
Be explicit about how released capacity would be used. It might reduce a backlog, allow better customer follow-up, or create room for another task. The time does not become a cash saving unless a relevant cash payment actually changes. Use Chapter 26's separate resource and cash views when making that claim.
Give a person who finds a source error credit for improving the process. Do not reward only the number of drafts produced. Otherwise, the scorecard can favor speed while making the checking work invisible.
Measure adoption with the right denominator
The constructed practice log contains twenty-five requests. Five are outside the proposed scope, leaving twenty eligible requests. Twelve eligible requests use the assisted drafting path; eight use the manual path.
Assisted uptake is therefore 12 ÷ 20, or 60% of eligible requests. Dividing by all twenty-five produces 48%, which answers a different question. Counting logins answers neither question.
The twelve assisted drafts include ten accepted on the first review and two requiring correction. First-review acceptance is 10 ÷ 12, about 83.3%. In the constructed record, both corrected drafts eventually satisfy the exercise criteria, but that does not erase the rework.
The two corrections concern a missing source reference and unclear next-step wording. They are not simulated bookings or other unauthorized actions. The example records editorial review states, not messages sent to customers.
Keep requests, drafts, review attempts, and people distinct. One worker may handle many requests. One request may produce several drafts. A high volume of prompts is not evidence of more completed work or better employee performance.
Count effort across the assisted path
For the twelve assisted cases, the hypothetical log assigns four drafting minutes and two review minutes to each case. The two corrections require six additional minutes each. Shared maintenance for the same exercise period adds sixteen minutes.
That gives 48 drafting minutes, 24 review minutes, 12 correction minutes, and 16 maintenance minutes: 100 minutes in all.
At an assumed nine manual minutes for each of those same twelve cases, the comparison is 108 minutes. The modeled capacity difference is eight minutes, about 7.4% of that assumed baseline. It is not a measured improvement, payroll saving, or finding about the eight different cases that took the manual path.
This modest result is more useful than claiming that four-minute drafts beat nine-minute manual replies by 56%. That comparison would omit the review, corrections, and maintenance required by the proposed workflow.
The log supplies no measured manual quality comparison, live customer outcomes, or evidence that the saved minutes were put to use. Those are gaps to resolve in a real evaluation, not blanks for AI to fill with optimistic prose.
Give feedback a visible route to resolution
Use a register with the concern, its source, the next action, owner, and status. Keep the person's identity only where needed and permitted.
The fictional feedback pack raises four issues: difficulty finding the current policy, concern about what logs will be used for, lack of scheduled review time, and a request for more readable training materials. These are constructed concerns, not quotations from actual employees or survey results.
A useful response is specific. For policy access, name the document owner and propose a clear entry point. For log use, document the permitted purpose and access. For workload, allocate review time. For readable materials, agree an appropriate format and check it with the intended user.
Do not mark a concern resolved because a response was drafted. Record whether the change was implemented and whether the relevant person or owner confirmed that it addressed the problem. Those fields remain blank in the supplied practice register.
Review the pilot at a real decision point
Choose the review date and proposed success conditions before examining the result. Include accepted output, complete effort, unresolved incidents, staff experience, and ongoing cost. Explain which conditions are essential and which are preferences.
A critical failure, such as disclosure of restricted information or an unauthorized commitment, should trigger the defined pause and recovery process. Do not keep the workflow running solely because its average score looks good.
NIST's AI Risk Management Framework provides a voluntary approach to considering trustworthiness throughout AI design, use, and evaluation. The pilot structure here applies that ongoing-review idea; it does not establish certification or replace legal duties.
At the review, choose among continuing within the current scope, revising and retesting, stopping, or proposing an expansion. Explain the evidence behind the choice. A narrow success does not authorize every new use of the same tool.
Draft the update without hiding uncertainty
Prepare a staff update from the supplied pilot agreement, task log,
and feedback register. State what is proposed, what was actually done,
what remains unresolved, and who owns the next step.
Report eligible-task uptake, first-review acceptance, full workflow effort,
and missing evidence using the stated denominators. Separate constructed
examples from real observations. Preserve dissent and unresolved concerns.
Do not infer employee attitudes, rank workers, announce approvals,
or promise changes to jobs, pay, privacy, or staffing that are not recorded.
The strongest update tells people what their input changed and what the evidence supports. Trust grows through a process people can inspect and influence, maintained through ordinary work after the launch meeting ends.
Next: Use the same discipline of evidence and accountability for business decisions in Chapter 31.