Software adoption
Your Team Isn't Using the New Software: A Two-Week Rescue Plan
Find the task that makes a new tool hard to adopt, repair the workflow, and decide whether to keep it without blaming the team.
The new tool looked wonderful in the demo. Two weeks later, the team is back in spreadsheets, email threads, and a folder called “Final_v3_really-final.” It is tempting to call that resistance to change. Sometimes it is. Often the ordinary work simply takes longer in the new system.
Before scheduling another training session, find out where the work gets stuck. This plan is for a small team with a tool already in place. The example is fictional, and it is not a report of testing any product. The aim is to decide whether the workflow can be repaired or whether the team has learned that the tool does not fit.
Start with one abandoned task
Ask each person to name the task they stopped doing in the new software and where they do it now. Avoid a survey that asks whether they “like the platform.” Someone can like the design and still need six clicks to send an invoice. Collect one concrete task from each role: creating a lead, updating a project, sharing a document, sending an approval, or checking a report.
Choose a task that matters every week. Watch someone perform it in the old way, then in the new tool, using safe sample data. Note the steps, missing information, interruptions, and any time they have to ask for help. Do not coach them through the task during the first pass; you are trying to see the workflow they actually have.
Write down the result in plain language: “The salesperson cannot see who owns a lead without opening three screens” is actionable. “The team is not engaged” is a slogan wearing a name badge.
Separate four different problems
| What people say | What may be happening | First repair to try |
|---|---|---|
| “I can’t find anything.” | Navigation, naming, or permissions are confusing | Make one shared starting view and check access |
| “It takes too long.” | The task has extra fields or duplicate entry | Remove unnecessary steps or connect the handoff |
| “I don’t trust the data.” | Imports, ownership, or updates are inconsistent | Audit a small sample and agree who maintains it |
| “I keep forgetting.” | The tool is outside the normal workday | Attach the task to an existing trigger or meeting |
These are hypotheses, not diagnoses. Test the smallest change that could solve one problem. If a field is missing because of a legitimate requirement, explain why it matters and make it easy to complete. If it exists only because the template had one, consider removing it.
Give the tool a job and an owner
Write a sentence beginning “We use this tool to…” and end it with a business task. For a service company, that might be “We use it to ensure each new inquiry has an owner and a next reply date.” If the sentence becomes “We use it to centralize everything,” try again. “Everything” is a large and suspiciously empty drawer.
Name one person to keep the workflow understandable. This owner does not have to perform everyone’s tasks. They maintain the definitions, answer questions, and note what needs fixing. Document the minimum rules: where a task starts, who updates it, what counts as done, and where to ask for help. A one-page guide beside the tool is more useful than a 40-slide presentation nobody opens twice.
If the issue is a CRM, our weekly follow-up routine offers a small set of stages and next actions. If the tool was chosen on a low subscription price, our total-cost worksheet helps account for setup and training time too.
Run a two-week rescue, not an endless rollout
Days 1–2: observe. Pick one recurring task and watch it happen. Save a baseline: how long it takes, how many handoffs it has, and whether another person can understand the result.
Days 3–5: remove one obstacle. Simplify a form, change a default view, clarify ownership, or repair an integration. Tell the team exactly what changed and what task to try again. Leave other settings alone so you can tell whether the repair helped.
Week 2: repeat with a different person. Ask someone who did not help configure the system to complete the same task. Compare the outcome with the baseline. If they still need a guided tour, write down where they get lost. The problem may be training, but it may also be the design of the workflow.
At the end of two weeks, decide to keep, adjust, or replace the tool. Make the decision with the people who use it and the person responsible for cost and data. Keeping a bad fit to justify the money already spent can be more expensive than learning from the trial and moving on.
Count completed work, not logins
An active-user chart can show that people opened a tool. It cannot show that they finished a useful job. Pick one or two measures tied to the task: inquiries with a clear next action, invoices sent without duplicate entry, or project updates another colleague can understand. Review a small sample manually. Numbers from incomplete records can create confidence without information.
If the tool stores customer data, check who can access it, how mistakes are corrected, and whether the team can export it. A smoother workflow should not rely on sharing one login or copying sensitive records into personal notes. Those shortcuts may make a trial look successful while creating a different problem.
What success looks like
Someone can complete the recurring task without a rescue call, the next person can understand the result, and the team knows whom to tell when the workflow breaks. That is a better sign of adoption than a wall of green activity dots. If the software cannot support that ordinary day, the team may be telling you something useful by returning to the old way.