An AI solution can perform well in a demonstration and still struggle to become part of everyday work.
People attend the training. They try the tool. Then, when deadlines tighten, they return to their familiar ways of working.
It is tempting to call this resistance to change. But that diagnosis can miss something more practical: the new approach may ask people to carry more effort, uncertainty or responsibility than the problem it solves.
In our previous article, we explored why individual productivity gains do not automatically improve business performance. Moving from Horizon 1 to Horizon 2 requires attention to the workflows that connect people, decisions and outcomes.
That raises a further question: what makes people willing and able to work differently?
A useful starting point is to examine the friction they experience.
Before pushing adoption, understand the hesitation
Imagine introducing an AI solution that employees use less than expected.
If leaders assume the problem is awareness, they may increase communication. If they assume it is capability, they may provide more training. If they assume it is motivation, they may introduce usage targets.
Each intervention can help when it addresses the actual problem. But none resolves a workflow that requires people to copy information between systems, check every output against its original source or complete the old process alongside the new one.
In those circumstances, hesitation contains useful information. People may understand the technology perfectly well. They may simply have discovered that using it makes their job harder.
Concerns about roles, trust and organizational change also deserve attention. The point is to investigate what people are responding to before deciding how to intervene.
Start with the job people need to get done
Clayton Christensen and his collaborators’ Jobs to Be Done theory offers a useful perspective: people seek solutions that help them make progress in particular circumstances. Understanding that progress helps explain why they choose one approach over another. Christensen Institute
Applied to workplace AI, this means looking beyond the feature being introduced.
An account manager needs to deliver a credible proposal that can be approved and fulfilled. A service agent needs to resolve a customer’s problem. A manager needs enough reliable information to make a decision and take responsibility for it.
“Use the AI assistant” is an activity within those jobs. Its value depends on whether it helps people complete them.
This changes the design conversation. Instead of beginning with everything the technology can do, begin with the circumstances in which someone must get a result.
What makes that difficult today? What do they need to trust? What happens if something goes wrong? What work remains after the AI has produced its answer?
Those questions bring the full cost of using the solution into view.
A better proposal tool can still create more work
Return to the hypothetical sales team from our previous article.
The organization introduces an AI proposal assistant. It produces a strong first draft, and the demonstration suggests a substantial saving in preparation time.
But account managers must collect customer information from several systems and paste it into a separate interface. They then check the suggested pricing, transfer the result into the approved template and record the details in the customer management system.
Delivery reviewers receive polished documents, but cannot easily distinguish confirmed requirements from generated assumptions.
The tool has accelerated drafting. Around that improvement, it has introduced preparation, verification and transfer work.
When account managers return to their previous approach, another training session may have little effect. The design needs to address the effort surrounding the draft.
A more useful approach could bring relevant information into the existing workflow, make its sources visible, flag missing requirements and separate confirmed facts from suggestions. Agreed details could then pass to the next stage without repeated entry.
That gives people a concrete reason to change: the new approach helps them carry the proposal further toward completion.
Test three kinds of fit
The carousel introduces three useful questions for evaluating an AI solution: workflow fit, job fit and agency fit. Together, they help turn a broad adoption problem into specific design decisions.
Workflow fit: does the solution work where the work happens?
Examine the steps before and after someone uses it. Consider access, information gathering, handoffs and duplicate entry. A capability that looks convenient in isolation may become cumbersome inside a working day.
Job fit: does it help someone reach the required outcome?
A plausible draft may be insufficient when the job requires an approved proposal. A summary may be insufficient when the recipient needs evidence for a decision. Evaluate how much useful progress the output enables and how much work remains.
Agency fit: can people exercise the judgment their responsibility requires?
Someone expected to stand behind an output needs a practical way to inspect it, correct it and handle exceptions. If accountability remains with the employee, the workflow must give them enough information and control to meet it.
These questions also reveal why the same solution can work well for one group and poorly for another. Their circumstances, responsibilities and downstream requirements may differ.
Create the conditions for pull
When a new approach removes a recognizable obstacle, people have a reason to return to it. That is the basis of operational pull: demand grounded in the work itself.
Creating it requires involving employees while the design is still open to change.
Ask people to walk through a recent case. Observe where they leave the system, seek clarification, repeat an entry or check something manually. Test the proposed approach against difficult cases as well as straightforward ones.
Then use what you learn to change the workflow.
Some temporary friction is unavoidable. People need time to learn, and a new process may initially feel slower. The important distinction is between the effort of becoming familiar with a better approach and recurring effort built into the design.
Training can address the first. Persistent duplication, unclear responsibility and poor information require changes to the solution or the surrounding process.
Leadership still has work to do. Teams need time to learn, support when something fails and clarity about which previous steps can be retired. A new workflow has a weak chance of proving its value if employees must maintain both approaches indefinitely.
Measure what adoption makes possible
Usage data can show whether people open a tool. It says less about whether the tool has earned a useful place in their work.
Look at whether people complete real cases with it, how much correction is needed and whether the next person receives a better input. Connect those observations to the business outcome.
For the proposal workflow, that could mean less preparation effort, fewer clarification loops and a shorter path to an approved offer.
This also preserves the lesson from the first article. A solution can be popular with one team while creating work for another. Adoption becomes more meaningful when the benefit survives the handoff.
Treat hesitation as evidence
Before increasing the pressure to adopt an AI solution, establish what people encounter when they try to use it.
Which obstacle has disappeared? Which new obligations have appeared? Can they complete the job with sufficient confidence? Does the next team benefit too?
The answers give leaders something concrete to improve.
An AI initiative earns a place in everyday work when people can experience its value in the job they are responsible for completing. Designing for that experience is part of delivering the business result.




