Business software adoption: how to test real usage before expanding

Before rolling a business system out across an organisation, check that people complete real work in it. Purchased licences and created accounts do not measure adoption. Define a pilot group, a recurring task and an identifiable outcome, then check who reaches it, who returns to perform it and who still works outside the system. That evidence helps you decide whether to expand, repair onboarding or change the product before buying or developing more.

What can a purchased but little-used system teach us?

In August 2024, Chalkbeat reported on a proposed Paper contract in Detroit. The discussion raised concerns about limited use in other districts. The superintendent explained that Detroit’s proposed implementation would place tutoring within the school day and pay when tutoring occurred. This is historical reporting on a proposal and the district’s explanation, not evidence of subsequent implementation results.

Our interpretation is that purchasing and using are separate decisions. One person approves a budget; another must make time and change a habit to obtain value. Measuring only the first can reveal commercial growth before anyone understands whether the service has entered everyday practice. This matters for internal systems even without subscriptions: investing in development does not guarantee employees will stop using the old spreadsheet.

What counts as evidence of adoption?

Choose an action that represents why the system is being purchased. In operations software, it might be a task moving from receipt to closure with all required information. In sales software, it might be an enquiry assigned and handled according to the process. A login can help diagnose access problems, but it does not prove the system helped someone do work. Define a starting state, an ending state and a person who can confirm the business meaning of each action.

Also define who should use the system and how often. Someone preparing a monthly report is not expected to log in daily. Dividing daily users by all company employees can therefore mislead. Instead, examine use relative to genuine opportunities to perform the task and within a suitable time window. In a small pilot, a short list of explained cases may be more useful than a precise-looking percentage based on very few events.

How do you design a pilot that supports a decision?

Choose a group representing the people who will need the system, including someone less familiar with it. Decide who provides training, who answers questions and how problems are recorded. Ask participants to perform a normal work task, rather than only a demonstration prepared by the provider. When a team member assists, record what required explanation; otherwise, you may mistakenly attribute successful completion entirely to the system.

Before starting, write down the decision to be made at the end and the evidence it requires. For example, you might require the group to complete a particular type of work without reverting to the old tool, with an agreed way to handle exceptions. This is an example decision criterion, not a universal numerical target. Do not select a threshold only after seeing results, or turn every difficulty into a development request without investigating its cause.

What if people do not return to the system?

Separate lack of opportunity from an actual barrier. Ask whether the task occurred, whether the person knew the system was available and whether they had permission and information to begin. Then identify where they stopped and what they did instead. Discussing a real case may reveal that the problem is information transfer between departments, rather than a missing button. Fixing the wrong thing adds functionality without changing the habit.

For each case, record the task, stopping point, alternative approach and proposed explanation. Test that explanation with a limited change, such as brief training or moving a necessary field onto the working screen. Compare the same task afterwards and record what remains unknown. Do not attribute every usage increase to a product change if the manager simultaneously introduced mandatory daily reporting or the workload changed.

How do you avoid misleading measurement?

In the Julius website integration check on 15 October 2026, clearly marked test enquiries were saved in CodeManage from both domains and the records were read back. With analytics consent, an enquiry-save event in Umami was also checked. The event therefore describes a saved enquiry, not a booked meeting. This is a measurement-integrity check on our own site, not a business result or a customer adoption study.

Apply the same principle to a pilot: an event name should describe what was demonstrated. Distinguish clicking submit from completion in the business system, and exclude test activity when drawing conclusions about real use. If privacy or consent settings leave some activity unmeasured, disclose that coverage limit. Observations and conversations can complement the data without bypassing consent or inventing users who were not measured.

What should the development team provide before expansion?

Request a summary linking tested tasks, remaining barriers and the cost of addressing them. Include measurement and expansion criteria in the technology product specification. If the system uses AI, also examine whether outputs are usable and how much human correction they need. The number of generated answers is insufficient, as discussed in our guide to choosing AI developers.

For a meeting with the Julius software team, bring one workflow and two pilot examples: a success and a blocked attempt. They make it possible to discuss expansion in terms of use and outcomes rather than screens or licences. Sometimes the next step is development; sometimes it is a change to training or operational ownership. The aim is to identify the investment that helps people perform the work for which the system was chosen.