How to get employees to actually use new internal software

The short answer

Employees use new internal software when it was shaped by the people who do the work, makes their own day easier within the first five minutes, and replaces the old way on a firm date. Involve two or three real users before launch, test with real work for a week, give each role a screen that shows only what they need, fix the first complaints fast, and retire the spreadsheet or group text it replaces. Measure weekly active users and how often people fall back to the old way.

Every owner has seen it happen. A new tool gets announced with real enthusiasm. For two weeks people use it. Then someone keeps a side spreadsheet "just in case", the crew goes back to texting the office, and by the next quarter the tool is a login nobody remembers. The software worked. The rollout did not.

The good news is that adoption is not luck or personality. It follows a small number of predictable rules, and most of them are decided before the tool is launched. This guide covers why internal tools get abandoned, a rollout plan that sticks, how to measure adoption and how to handle the pushback you will get.

Why people stop using new tools

People do not abandon tools that make their day easier. They abandon tools that do not fit, add work, or compete with an old way that never went away.

Cause	What it looks like	The fix
The tool misses a real need	A side spreadsheet appears within a week	Ask what is missing and add it fast
It adds steps	People enter the same information twice	Remove fields nobody uses; enter each fact once
It shows everyone everything	Staff scroll past screens that are not theirs	Give each role its own screen
The old way still works	Half the team uses the tool, half the group text	Set and hold a switch-over date
Nobody owns it	Questions go unanswered, small problems pile up	Name one owner who can change it
It is hard to use on a phone	Field staff call the office instead	Design the field screens for phones first
People do not trust the data	Managers double-check everything by phone	Test with real work before launch; fix errors fast

Every row above is a design or process problem, not a people problem. That is good news, because design and process are things you control.

The cost of getting it wrong

A tool that half the team uses is often worse than no tool, because now information lives in two places. Asana's Anatomy of Work research reports that workers spend 60% of their time on "work about work", like chasing status and searching for information. A Zapier survey of businesses with up to 250 people found repetitive tasks take an average of 17.3 hours a week. A half-adopted tool adds to both: people check the tool, then check the spreadsheet, then text someone to be sure.

Your team is not starting from zero

Many of your people are already comfortable with new tools, and some are ahead of you. According to Gallup, as of May 2026, 15% of U.S. employees use AI daily in their role and 30% use it a few times a week or more. PagerDuty and Wakefield Research reported in June 2026 that two-thirds of office professionals who use AI at work have used AI tools they believed were not permitted.

That second figure is worth reading as a lesson about adoption. People adopt tools on their own, even against the rules, when the tool helps them. Your job is to make the approved tool the one that helps most.

Adoption starts before the build

The single biggest predictor of whether a tool gets used is who shaped it. A tool designed by someone in the office, for people they have never watched work, will miss things. A tool described by the people who do the work fits the real process, including the exceptions that make or break it.

Let a user describe the tool. The dispatcher describes the dispatch board. The crew lead describes the inspection app.
Ask what they would hate. "What would make you stop using this?" catches problems earlier than "What do you want?"
Copy their words. Use the status names, field names and job names your team already says out loud.
Name the exceptions. Cancellations, rush jobs, missing information. If the tool cannot handle the messy cases, people will handle them outside it.

A rollout plan that sticks

Choose one owner. The person who does the work and will answer questions after launch.
Write down today's process, including the three most common exceptions.
Build the first version from that description.
Pick two or three testers, including at least one skeptic. A skeptic who is won over is worth ten enthusiasts.
Test with real work for one week, alongside the old way.
Fix every complaint you can within days. Speed here earns trust for everything after.
Announce the switch-over date at least a week ahead, with the reason in one sentence: what it saves the team.
Train by role, in five minutes. Show each person their own screen and the two or three things they will do every day.
Switch over and retire the old way. Make the spreadsheet read-only. Stop answering the group text with job updates; point people to the tool.
Check in at one week and four weeks. Ask what is missing, measure usage, and make changes.

Example: rolling out a job report app to a field crew

Example: a 28-person HVAC company wants technicians to file job reports with photos in an app instead of texting pictures to the office. The service manager owns the rollout. He asks two senior technicians, one of whom is openly skeptical, to describe what a report should include and what would annoy them.

The skeptic says he will not type long notes on a phone in a crawl space. So the app gets quick-pick buttons for the ten most common findings, a photo button that works with gloves on, and an optional note. The two technicians test it for a week. They ask for one change: the job list should show today's jobs only, in route order. The service manager makes the change, announces the switch-over for the following Monday, and shows each technician the app in a five-minute huddle. From that Monday, the office stops accepting job photos by text. The skeptical technician now explains the app to new hires.

Make the first five minutes count

People decide quickly whether a tool is on their side. Design the first five minutes for each role.

Field staff: today's work, in order, on a phone, with one tap to update status.
Office staff: a list of what needs their attention now, not everything that exists.
Approvers: pending items with the information to decide, and approve or reject in one step.
Managers: a summary of what is open, late and done, with the ability to drill in.

If a person has to scroll past other people's work to find their own, the tool feels like it was built for someone else.

Trust is part of adoption

People will not rely on a tool they do not trust, and trust has two parts: the data must be right, and the data must be safe.

On accuracy, experienced users already expect to check AI-made work. In Stack Overflow's 2026 survey, 48% of developers said they trust AI output when they can easily verify it. Microsoft's 2026 Work Trend Index found that 86% of AI users treat AI output as a starting point. That is why testing with real work before launch matters: it is how your team verifies the tool before they depend on it.

On safety, employees notice when tools are careless with data. In February 2026, The Register reported that researcher Taimur Khan found 16 vulnerabilities in a single app hosted on Lovable, exposing 18,697 user records. A tool that leaks coworkers' or customers' details loses the team's trust, and rightly.

And for the people building and refining tools, the frustration with almost-right results is real: in Stack Overflow's 2025 survey, 66% of developers named "AI solutions that are almost right, but not quite" as their top frustration. If every fix costs more credits, builders stop fixing and users stop using. Choose a platform where refining a tool is cheap.

Measuring adoption

Measure	How to get it	Healthy sign after four weeks
Weekly active users	The tool's own activity record	Close to everyone who should be using it
Work entered in the tool	Compare items in the tool to items in the old channel	Old channel close to empty
Side spreadsheets	Ask managers and look for them	None for this workflow
Questions to the owner	Count them weekly	Falling week by week
The original problem	The number you measured before launch	Clearly better

Handling the pushback

"The old way was faster." It may have been, for one person. Show what the tool saves the next person in the chain, and look for a step you can remove.
"I don't have time to learn this." Five minutes, their own screen, two actions. Then sit with them for their first real entry.
"It doesn't handle my situation." Take it seriously. Add the exception if it is common, or agree how to handle it if it is rare.
"I'll just text you." Kindly, consistently, point to the tool. Managers have to hold this line or the old way comes back.

A launch checklist

The tool was described by someone who does the work.
At least one skeptic tested it.
Each role has its own screen.
Every common exception is handled.
Testers' complaints are fixed.
The switch-over date is announced, with a one-sentence reason.
Role-based training takes five minutes or less.
The old spreadsheet or channel will be retired on the date.
One number from before launch is written down.
Check-ins are booked for one week and four weeks after.

How FORGE handles it

FORGE is built for tools that get used, because the people who do the work describe them. A panel of top AI models plans each tool, a dedicated AI crew builds it, and every piece is checked for quality and security before it is saved. Most teams have their first real tool the same day, as a web, mobile or desktop app, so field staff get phone screens and the office gets a full view.

Roles for owners, admins, builders and app users mean each person sees what is theirs. Every app lives inside your company, people join by invite only, and a complete record shows who did what, which is how a team learns to trust a tool.

Refining is cheap, which is what adoption needs: changes are a small fraction of a build and only count when something changes. A seat is $49 a month with 3 builds, app users are free, a build FORGE fails is free, packs of 10 builds are $150, caps and alerts arrive at 80 and 100 percent, and nothing bills by itself. Our onboarding starts with a workflow workshop that includes the people who will use the tools, not just the people who buy them. Talk to us or see how it works.

Questions people ask

Why do employees stop using new software?

Usually because it misses something they need, so they keep a side spreadsheet; because it adds steps instead of removing them; or because the old way was never retired. Resistance to change is real, but most abandonment comes from a tool that does not quite fit the work.

How long does it take for a team to adopt a new tool?

For a simple internal tool that replaces a spreadsheet or group text, most teams settle in within two to four weeks if there is a firm switch-over date. Without one, adoption can drag on indefinitely.

Should we train everyone before launch?

Keep training short and specific to each role: five minutes showing each person their own screen and the two or three things they will do every day. Long training sessions on every feature are forgotten quickly.

What if a senior employee refuses to use the new tool?

Find out what they lose. Often it is a shortcut or a view they relied on. Add it if it is reasonable, show them the time it saves them, and hold the switch-over date. Their manager should make clear the old way is retired.

How do we measure adoption?

Track weekly active users against the number of people who should be using the tool, the share of work items entered in the tool rather than elsewhere, and how many questions or side spreadsheets remain after the switch-over.

Does it help if employees build the tools themselves?

Yes. A tool described by someone who does the work fits the real process, including the exceptions, and that person becomes its champion. Their coworkers trust it because one of their own made it.

See what FORGE builds for your team

We onboard every team ourselves, starting with the work that costs you the most time.

Talk to us