Your employees aren’t the bug. The software might be.

Your employees aren’t the bug. The software might be.

When people avoid a new internal app, “resistant to change” is a convenient diagnosis. It lets the buying decision, the requirements and the implementation escape the same scrutiny as the people expected to use it.

Before sending another reminder to log in, find out what happens when someone tries to finish a real piece of work.

They may need training. They may also be keeping the business running around a gap you paid someone to build.

The spreadsheet nobody mentioned in the launch meeting

Imagine a repair business that buys a new job-management app. This is an illustrative example, not a client story.

The app records the customer, the equipment and the appointment. Management gets a tidy view of open jobs. But a technician cannot record that one replacement part has arrived while another is still on order. The job is either waiting for parts or ready to schedule.

The coordinator keeps a spreadsheet with the missing detail. Before calling a customer, they check the app, the spreadsheet and an email from the supplier. At the end of the day, they update the app so the dashboard looks current.

You could call this poor adoption. I would want to know why the officially approved tool cannot represent the situation the coordinator handles every Tuesday.

Making the spreadsheet forbidden does not create the missing capability. It can make the work harder to see.

Even a capable AI tool can lose people along the way

Microsoft published a useful example on October 8, 2026, about adoption of its Employee Self-Service agent. Its internal research found that technical performance alone did not explain whether employees used the service. People could arrive after trying other fixes, encounter repeated suggestions and be unsure how to reach a person.

The resulting design work addressed prior context, limitations and escalation. This is Microsoft’s account of its own rollout, not proof that the same changes will produce the same results in another business.

What I take from it is that people judge the whole route to getting help. A good answer halfway through a frustrating process does not finish their task.

That applies to a conventional business app too. A screen can work exactly as specified while the process around it remains a nuisance.

The side process is worth investigating

A spreadsheet, a copied message or a paper note can reveal information the app cannot hold, a handoff it cannot complete or a decision nobody has agreed on. Sometimes it reveals a preference for the familiar. You have to look before deciding which.

I would start with one person who does the work regularly. Ask them to complete a representative task using realistic, appropriately protected data. Let them take their usual route, including the steps outside the app. Ask why those steps exist.

Then follow the work to the next person. The first user might save time by leaving a field blank while a colleague spends longer finding the answer. A faster screen is not necessarily a faster process.

In the repair example, the useful finding might be quite small: track parts separately from the overall job status, make the outstanding item visible, and show who is waiting for it. That is a specific improvement to investigate. It is not an automatic reason to rebuild the whole application.

A complaint about slow screens may need a performance fix. Repeated copying may need an integration. Unclear responsibilities may need a management decision before any code changes. Selling the same solution to all three would be lazy consulting.

Necessary controls still count as work

None of this means every unpopular step should disappear. A second approval, an access restriction or a required record can protect the business. Familiar shortcuts can also lose information or expose data to the wrong people.

The question is whether a step serves a clear purpose and whether the software makes it needlessly difficult. Keep the control when it is needed. Explain it, give the right people access, and remove duplicate entry around it where possible.

Training deserves the same distinction. Teaching someone an unfamiliar but useful process is worthwhile. Teaching them how to repeatedly recover from an avoidable defect is a workaround with a training budget attached.

Give the developer a problem they can verify

“Improve adoption” is too vague to be a useful development brief on its own. For the repair business, a better brief would be: let the coordinator see which parts are still outstanding and arrange the appointment without reconciling a separate spreadsheet.

Agree how you will check that. Include a partial delivery, a wrong part and a changed appointment. After the change, watch the same work again. Record completion time, corrections and outside steps, and check whether another person inherited extra work.

Those observations can support a sensible next decision. Login counts alone cannot tell you whether the new process is better, especially if logging in is mandatory.

I would also give any temporary parallel process an owner and an exit condition. Running both systems while checking a migration can be responsible. Leaving everyone to maintain both indefinitely needs a reason.

The developer should leave you with a clear account of the gap, the proposed fix and how you will know it helped. If the app already supports the task and the real problem is training or an unresolved policy, that should be the finding.

Bring us the workaround

At Rosecraft, we work on business applications, integrations and existing systems. If your team is working around software you already bought, a focused review can be a better starting point than a replacement proposal.

Ready to hear what needs fixing, even if it challenges the original plan? Tell us what your team is trying to finish, where the app gets in the way and what they do instead. Describe the workflow without sending passwords or customer records. We can discuss a scoped review and the implementation it actually calls for.

Your staff’s workaround may be the most useful requirements document you have.