Change management is the hardest part

Imagine a buyer opening a supplier’s file before placing an order. One column says “length.” It doesn’t say inches or centimeters. The buyer knows to ask before using the number.

Now give that buyer an agent that turns the file into a tidy set of records. The records arrive faster. Someone still has to settle what the supplier meant.

If the buyer still has to reopen every file and keep notes to avoid investigating the same question next week, much of the old job remains. The buyer has also acquired a new job: checking the agent.

Keeping the spreadsheet is a reasonable response to that arrangement. The buyer still answers for a bad order and needs a way to explain how it happened.

Aaron Levie’s post above describes how much work surrounds an enterprise AI system: connecting systems, preparing data, changing procedures and arranging human review. Part of that work is deciding what someone can safely stop doing.

The cost of checking

A demo can end when the agent fills in the record. The buyer’s job ends when the order is ready. Between those two points sit the questions that determine whether the tool saves any time.

Can the buyer see the supplier’s original number beside the result? Does an unresolved unit stay visibly unresolved? When the buyer confirms the answer, does the correction reach the next person who needs it, or only the person who typed it?

Those details affect how much checking is necessary. If the next import overwrites a confirmed correction without warning, keeping a private note is sensible. Asking the buyer to trust the tool won’t make the correction persist.

There’s also a question of who benefits. A manager may get a report sooner while the buyer spends longer preparing it. Calling that a time saving hides where the work went. Measure the buyer’s time too, including the minutes spent finding and repairing mistakes.

Where the change gets stuck

Prosci’s ADKAR model describes five things a person needs for a change to last: awareness, desire, knowledge, ability and reinforcement. A useful distinction here is between knowing how to use a tool and having a reason to use it. The buyer may understand every button and still be better off with the spreadsheet.

That distinction changes the next step. If the buyer doesn’t know how to correct a record, teaching helps. If correcting it requires permission they don’t have, someone must grant it. If the tool creates more work than it removes, the tool needs work. Treating all three as a training problem leaves two of them untouched.

Kotter’s approach includes getting people to lead the change together, removing barriers and demonstrating early results. For this buyer, that could mean involving the manager who still requires a separate spreadsheet report. Until that requirement changes, the buyer has to maintain both systems, however good the agent becomes.

These are ways to investigate a stalled change. Completing the framework doesn’t tell you whether the buyer’s morning got easier.

When the old file can go

Try the new process on a small batch of real work. Follow it through checking, corrections and approval. Compare the time and errors with the old process, and ask the buyer to show you every note they still keep elsewhere. Each one may point to something the new system hasn’t accounted for.

Some duplicate work is useful while testing. Give that comparison an end: agree on the results you need, who can approve the switch and how work will continue if the system fails. Once those conditions are met, stop requiring the old report.

The spreadsheet can stay available as a fallback without remaining a second daily obligation. The buyer should be able to check the record, place the order and move on.

Original post by Aaron Levie, September 30, 2026. Commentary by Sam Sugarman, September 30, 2026.

Framework sources: Prosci’s ADKAR model and Kotter’s eight steps for leading change. The supplier example is illustrative; the applications of these frameworks are our own.