Getting people to actually
use procurement software

Adoption problems are usually described as cultural. People are resistant, or set in their ways, or need more training. That framing is comfortable and almost always wrong.

People adopt tools that make their day easier and avoid tools that do not. If raising a compliant request takes fifteen minutes and asking a colleague takes two, they will ask the colleague, and no amount of training changes that arithmetic.

So adoption is a design question. The rollouts that stick are the ones where the compliant path is genuinely the fastest path available.

Why rollouts fail

Four causes account for most of it, and only one of them is about people.

The form is too long. Every field you add is an argument for the informal route. Fields that could be inferred, defaulted or made conditional should be.

The catalog is thin. If half of what somebody needs is missing, they learn the catalog is unreliable and stop checking it. This is the most common cause and the most avoidable.

Approval is required for everything. Requiring sign off on a small purchase signals the process is not calibrated, and people treat the rest of it accordingly.

Approvers cannot act from a phone. Delay caused by approvers being at a plant or between meetings gets attributed to the system.

Speed is the whole strategy

The target worth setting is a request in about two minutes. Not because two minutes is magic, but because it is faster than the informal alternative in almost every organisation.

Getting there means being ruthless about the form. Six fields, most of which remember themselves or come from the catalog. If a field exists because somebody in finance might want it later, question whether it earns its place at the point of request.

Every field you add to a request form is a small argument in favour of the workaround.

The catalog decides it

If we could only fix one thing before a rollout, it would be catalog depth. It is the single strongest predictor of whether adoption holds.

Load the things people actually buy, which you can find by looking at last year's transactions rather than by asking. Start with the items that account for most of the request volume, not most of the value.

Then watch what gets requested off catalog and add it. Those requests are telling you precisely what is missing.

Why mandates backfire

Mandating use is tempting because it looks decisive. It works poorly for two reasons.

First, it converts a design problem into a compliance problem, which means the underlying slowness never gets fixed. Second, it creates resentment that outlasts the rollout, and the people who resent it are the ones who will decide whether the next initiative succeeds.

The better approach is to make the compliant route quicker and let people find it. Most rollouts that reach high adoption did so without anybody being ordered to comply.

Rollout sequence

Start with the module that helps the requester, not the one that helps finance. Intake and approvals is usually right, because approval delay is what people feel daily.

Starting with purchase orders or invoice matching means the first thing the business experiences is a new obligation with no visible benefit, which sets the tone badly.

Measuring adoption honestly

Count the share of purchases going through the platform rather than the number of logins. Logins measure curiosity, and they peak in week two regardless of whether anything is working.

Watch off catalog requests as a signal rather than a problem. A rising count usually means the catalog is behind rather than that people are misbehaving.

And ask requesters directly at week four. They will tell you what is slow, and it will usually be one specific field.