How to Get Team Buy-In on New Software

Turn this article into takeaways for your work.

Summarize with ChatGPT Summarize with Claude

Each assistant summarizes the article only for you and suggests best practices for your work.

Updated September 2026.

Team buy-in gets treated like a launch problem: pick a good tool, then convince people to use it. That order is backwards. By the time a contract is signed, the people who'll use the software every day have usually already decided, quietly, whether it's theirs or something that happened to them, and that decision got made during evaluation, weeks before anyone announced a go-live date.

If you haven't picked finalists yet, how to build a software shortlist covers narrowing a crowded category down to a defensible few. This guide picks up from there: who to bring into that process, how to run it so the people who'll use the tool have a real stake in the outcome, and what to do when the buy-in you thought you had doesn't survive contact with week three.

Key Facts: what decides whether new software actually gets used

  • Purchases decided by a cross-functional team saw 54% dissatisfaction within 18 months, versus 61% for IT-only decisions and over 67% when non-IT staff decided alone, in a Capterra survey of 3,400+ businesses reported by CIO Dive.
  • The average B2B buying group runs 10 or more people on a purchase near $250,000, per 6sense's 2025 B2B Buyer Experience Report, rarely the same 10 people who'll actually log in every day.
  • A mid-sized organization of 1,000 employees loses an estimated $10.9 million a year to poor digital adoption, and workers lose 728 hours annually navigating tools that never stuck, per a Whatfix-commissioned Forrester Consulting study.
  • Organizations leave an average of 36% of their SaaS licenses unused, per Zylo's 2026 SaaS Management Index, and unused seats are usually the first hard evidence that a rollout never earned real buy-in.
  • Three in five software buyers (60%) regret a purchase within 18 months, with slow or difficult implementation the second most-cited reason, per the same Capterra survey, reported by TechInformed; a stalled rollout and a regretted purchase are often the same event described from two different desks.

What buy-in actually means, and what it isn't

A quiet kickoff meeting where nobody objects looks like buy-in. So does an enthusiastic executive sponsor, or a pilot report with good scores. None of those things are buy-in. They're the absence of visible resistance, which is a different, much weaker thing, and the gap between the two is exactly where rollouts quietly stall three months in.

Real buy-in is specific: the people who'll use the tool daily understand why it was chosen, had a real hand in some part of the decision, and believe using it is genuinely easier than whatever they were doing before. Performative buy-in is compliance dressed up as agreement, and it holds only until the first real friction.

Signal Looks like buy-in Is actually buy-in
Silence in the kickoff meeting Nobody objects out loud The decision owner explained the tradeoffs and the room actually understood them
Executive enthusiasm Leadership is excited about the tool The people using it daily helped choose it, not just heard about the choice
Fast logins in week one People open the tool because they were told to People open the tool because it's genuinely faster than the old way
A glowing pilot report The pilot group liked the demo The pilot group tested it against their own messy, real work
No complaints in week one Nobody's pushed back yet Nobody's hit the gap yet; the real test is month two or three

None of these five pairs is obvious from the outside in the first weeks. That's the trap: a rollout can look successful on politeness alone, and by the time the gap shows, it's harder and more expensive to close.

Why evaluation is where buy-in is actually won

Most teams handle buy-in as a communications problem: pick the tool, then run a town hall, an FAQ deck, and a change-management template once the decision is already locked. By that point it's too late for the mechanism that actually produces buy-in, which is being part of the decision rather than being informed of it afterward.

The evidence for this is blunt. In the same Capterra survey cited above, purchases made by a genuinely cross-functional team saw 54% dissatisfaction within 18 months, versus 61% for IT deciding alone and past 67% for non-IT staff deciding without IT. The tool wasn't different across those three groups; who got to shape the decision was. A polished rollout communications plan doesn't close a gap that opened during requirements and shortlisting.

That gap opens in specific, nameable ways, and each one is avoidable once you know where to look.

Evaluation stage What quietly kills buy-in here Why it's easy to miss at the time
Requirements Written by the same one or two people who always write it, without asking who lives in the workflow The brief still looks thorough; thoroughness isn't the same as representation
Shortlist Finalists picked from a demo the daily users never sat in on Feels efficient; the team finds out what they're getting at rollout instead of at shortlisting
Trial Trial access limited to managers and the project sponsor The trial answers "does this work" for the wrong audience
Vendor selection The decision framed as a "feedback session" when it's already been made People can usually tell a staged decision from one that's still genuinely open
Contract and rollout planning Nobody asks the daily users what would make this fail specifically for them The rollout plan solves the problems leadership can see, not the ones on the floor

The SaaS vendor evaluation scorecard covers scoring finalists on a shared, weighted rubric once you have a shortlist. The fix for buy-in specifically isn't a better rubric, it's who's sitting at the table scoring alongside you, which is the next question.

Who belongs in the room, and when

Getting the roster right matters as much as the process. Too few voices and the decision reflects one person's taste dressed up as a team call. Too many and nobody's accountable, so the loudest voice wins by default.

Role When to bring them in What they catch What happens if they're skipped
Decision owner Start to finish Keeps the process moving and breaks ties Nobody owns the outcome, so nobody owns the fallout either
Primary daily users (2 to 4, not the whole team) Requirements through the trial Whether the tool fits the real workflow, not the demo version The rollout solves a manager's problem, not theirs
The informal skeptic Trial and pilot Whatever objection is coming anyway, surfaced early instead of at rollout Their objection shows up in week three as quiet sabotage instead of week one as feedback
Team lead or manager Requirements and rollout planning Workload and timing realities a vendor demo won't show you The rollout lands in the middle of a deadline nobody flagged
IT or security Shortlist and contract review Integration and access-control risk A blocked rollout after the contract's signed, the most expensive place to find this out
Finance Contract review Whether the real cost, including seats nobody will use for months, actually holds up A renewal surprise nobody budgeted for
Executive sponsor Brief sign-off and the final decision only Organizational priority and budget backing Absent when cover is needed, or so early that their opinion quietly becomes the shortlist

Keep this roster deliberately small. The point isn't maximum representation, it's making sure the two or three people whose daily work is actually affected are in the room before the decision. A stakeholder map with twelve names on it usually means nobody on it has real influence.

The objections you'll hear, and what they really mean

Every rollout produces a handful of predictable objections, and the mistake is answering the words instead of the concern underneath them. The same response, a bigger deck or a longer demo, gets reused for objections that have almost nothing in common.

What you'll hear What it actually means The response that works
"This is just extra work" Nobody's shown me the math for my specific job, only the department-level pitch Walk through one of their actual tasks, before and after, not the general case
"We already have a workaround that's fine" I built that workaround, and replacing it feels like losing ownership, not gaining a tool Ask them to help design how the new tool replaces the workaround, not just to adopt it
"Nobody asked us before this was decided" I found out about this the way I'd find out about a reorg, and that's not how buy-in starts Say so directly if it's true, and put them on the pilot group for whatever's still genuinely open
"The last tool we tried didn't work either" I've been burned before and won't spend the effort again until I see real proof Name what's specifically different about how this rollout is run, not just the tool
"I don't have time to learn a new system" My current workload has no room for a learning curve, whatever the tool's real merits Timebox training to the smallest slice that makes their actual job faster first
"IT picked this and doesn't understand what I do" The requirements brief never included anyone who does my job Loop them into the pilot with their own real records, run as a real trial, not a demo

None of these six objections is really about the tool's feature list. Answer the underlying concern and the surface objection usually resolves on its own; answer only the surface version and it comes back in a different costume three weeks later.

Running a pilot people can actually influence

A vendor trial and a buy-in pilot answer different questions, and conflating them is a common mistake. The trial proves whether the tool fits the work at all; how to run a software trial covers setting that up properly, with real data and a decisive question written down before anyone gets access. A buy-in pilot is a narrower, later exercise: giving the people who'll use the tool daily actual influence over how it gets configured and rolled out, not just an early preview of a decision that's already final.

Pilot design choice Weak version Version that builds real buy-in
Who's in it Whoever happens to be available that week The people most likely to raise the objection nobody's heard yet
What they're testing The vendor's demo workflow Their own real task, run the way they'd actually run it
What their feedback does Gets logged and rarely surfaces again Visibly changes at least one configuration choice inside the pilot window
Who decides based on it The project sponsor alone, after the fact The pilot group gets a real vote on one genuinely open decision, like default views or notification rules
How it ends A survey nobody circles back on A short readout, in the pilot group's own words, of what changed because of them

The version that actually builds buy-in requires giving up something real: a configuration choice you'd otherwise make unilaterally. That's the whole mechanism. People don't need to win every argument to feel like stakeholders. They need to win at least one, and see that it stuck.

The person who blocks it

One person rarely speaks for the whole team's opinion, but a vocal blocker is often the strongest predictor of whether everyone else commits early or waits to see which way the fight goes. The mistake is treating every blocker as the same problem with the same fix. They're usually not the same problem at all.

Type of blocker What's actually driving it How to handle it
The workaround loyalist Built the spreadsheet or shadow process everyone quietly relies on Give them a real role migrating what they built, not a replacement that erases the credit
The previously burned skeptic Sat through a failed rollout before; distrusts the process, not this tool Show them exactly what's different this time; don't ask for trust on faith
The power-loser The new tool removes a gatekeeping role they held in the old system Name the loss directly and find them a real role in the new setup, ideally a visible one
The overloaded manager A genuine capacity problem, not resistance to the tool itself Move their team's rollout wave; don't argue someone out of a real scheduling constraint
The informal leader others are watching Hasn't said no or yes; the team is waiting to see which way they land Get their real objection in private, before the group meeting

Match the fix to the type. A power-loser doesn't need more demo time, they need a real answer to what they lose. An overloaded manager needs their wave moved, not convincing. Treating all five the same way is how a single legitimate objection gets dismissed as generic resistance, right before it turns out to have been the one worth listening to.

Sequencing the rollout so buy-in survives contact with reality

The order people get access in matters almost as much as who's in the room during evaluation. A badly sequenced rollout can undo weeks of real buy-in work in its first two weeks.

Wave Who goes first Why
1: Pilot group The people who already helped shape the configuration They're invested, and their early wins become the proof the rest of the team asks for
2: Willing early adopters People who weren't in the pilot but reacted positively to it Momentum spreads faster from a peer than from a project sponsor's announcement
3: The bulk of the team Everyone else, once the workflow's proven on real work, not demo data By now the questions get answered by colleagues, not a slide deck
4: The skeptics and known blockers Last, once the tool has a track record inside the building Arguing an abstract case is harder than pointing at a peer already using it well
Never: everyone at once - A single go-live date turns every unresolved objection into one fight happening at once, with no room for real attention

Category-specific rollout mechanics matter here too. The CRM implementation guide and the help desk migration guide both cover what a real, staged cutover looks like once the sequencing above is decided, including where data migration timing collides with a rollout wave if you don't plan for it.

What to measure in the first 90 days

Waiting for the quarterly business review to check whether a rollout worked is waiting too long; by then a stall has had months to calcify into a habit. A short set of signals, checked weekly at first, catches most problems while they're still a conversation instead of a renewal decision.

Metric What it tells you Red flag
Active usage vs. licenses assigned Whether adoption is real or just provisioned A wide, growing gap; Zylo puts the average unused share at 36%, common but fixable early
Workaround usage Whether the old spreadsheet or shadow process is still doing the real work The workaround is still updated more recently than the new tool
Task completion time on real work Whether the tool is actually faster once the training-wheels period ends Still slower at day 60 than the old process was on day one
Support ticket volume and type Whether friction is technical (fixable fast) or workflow-shaped (deeper) Tickets shift from "how do I" to "this doesn't work the way my job does"
Manager check-in sentiment The qualitative read a usage dashboard misses entirely A manager reports the team "is using it" but can't name one specific task it made easier
Pilot-group retention Whether the people who chose this are still using it by choice, not habit Even the pilot group has quietly reverted to the old way

The $10.9 million figure cited earlier is what poor adoption costs a 1,000-person organization annually, and it's why this measurement window is worth the discipline. Catching a stall at day 30 costs a conversation. Catching it at month nine costs a renewal decision, and by then it looks a lot like the buyer's remorse covered here, just arriving from the adoption side instead of the contract side.

When adoption stalls three months in

Some stalls are still fixable at the three-month mark without starting over. Others are the first hard evidence that the fit was wrong from the start, covered in the next section. Telling the two apart starts with naming the actual symptom rather than reaching straight for "we need better training."

Symptom at month three Likely cause What to do
Usage clusters in the original pilot group only The rollout never really left wave one Reset the sequencing, not the messaging; find out what's actually stalling wave two
High login counts, low real use The tool became a compliance checkbox, not a working habit Measure what people build or complete in it, not whether they opened it
One team adopted fully, another refuses The refusing team never had a real stakeholder in the room during evaluation Backfill representation now; bring in a real user from that team mid-course
The original champion has moved on or left Ownership was never formally transferred to anyone else Name a new owner explicitly; enthusiasm doesn't transfer by osmosis
Workaround usage is climbing back up The tool solved a manager's problem, not the daily user's Re-run the "what would make this fail for you" question with the people doing the work

A stall that traces to sequencing, ownership, or a missing stakeholder is usually recoverable inside a month once you name the cause and act on it. A stall that persists after all five get fixed is a different signal, worth reading honestly rather than running the same playbook twice.

When the team is right and the tool is wrong

Sometimes what looks like a stalled rollout is actually the team correctly identifying that the tool doesn't fit, and no amount of change management closes that gap. It's worth naming directly instead of defaulting to "we just need to try harder."

Signal Points to an adoption problem Points to a genuine fit problem
Which teams struggle Struggle is scattered and inconsistent across similar roles Every team doing a specific type of work struggles the same way, consistently
What the workaround replaces People skip a step out of habit or unfamiliarity People skip a step because the tool genuinely can't do it
What training changes A short walkthrough resolves most of the complaints The same complaint persists after real training, from people who clearly understand the tool
What the pilot group says now The pilot group still prefers it; the holdouts are the actual issue Even the pilot group, months in, has quietly reverted
What it would take to fix A configuration change, a better rollout wave, a clearly named owner Nothing short of a different tool actually addresses it

If the table points toward a fit problem, the honest move isn't another round of training. It's back to the shortlist with what you learned added as a real requirement, or a hard look at whether to fix or replace what's live, which this guide on avoiding buyer's remorse walks through. Buy-in was never going to save a tool the team correctly identified as the wrong one.

The decision framework

Where you are What to do next
Still writing requirements Bring in 2 to 4 daily users now, not after the brief is finished
Building the shortlist Let the pilot-eligible team see finalists before the decision gets framed as already made
Running the trial Give the pilot group real data and one genuinely open decision to make
About to sign Name the rollout owner and the sequencing plan before the contract, not after
Rollout underway Measure usage weekly for the first 90 days, not just at the next quarterly review
Adoption stalling at month three Diagnose sequencing and ownership before running another round of training
Confirmed it's a fit problem, not an adoption one Go back to the shortlist with the new requirement; don't keep pushing the same tool

Frequently asked questions

Who should own getting buy-in: the project sponsor or the manager whose team will use it?

Both, with different jobs. The sponsor owns budget, timeline, and organizational priority. The team's own manager owns whether the daily users trust the process, and that trust doesn't come from a title. It comes from the manager actually representing their team's concerns during evaluation, not just announcing the decision once it's made.

How many people should actually be in the evaluation, versus just kept informed?

Full participation for 2 to 4 daily users plus the decision owner is usually enough. More voices doesn't automatically mean more buy-in; 6sense's research on B2B buying groups shows committees on larger deals routinely running past ten people, which mostly slows the decision. Keep the room small, and make sure the right small group is in it.

What if leadership has already decided which tool to buy before evaluation starts?

Then the honest job left is finding where the team's remaining influence actually is: usually rollout sequencing, configuration, and pilot design, not the vendor itself. Say that plainly rather than running a fake evaluation with a predetermined outcome. People can tell the difference, and the pretense costs more trust than skipping the theater would.

Does buy-in matter as much for a small team tool as for a company-wide rollout?

Arguably more. A five-person team adopting a tool for its own workflow has none of the organizational momentum that a company-wide rollout can lean on to survive a rough first impression. There's no wave two and wave three to build proof from if wave one doesn't stick.

How long should we wait before deciding a stalled rollout is a fit problem, not an adoption problem?

Long enough to run one real diagnostic pass, usually around the 90-day mark, not a gut call the week after launch. A configuration or sequencing fix caught early is cheap. Mistaking a genuine fit problem for a fixable adoption issue for another two quarters is not.

Should the person who championed the purchase also own the rollout?

Ideally yes, for continuity, but name a backup from day one. Champions change roles or leave, and a rollout with no named owner once the original champion is gone is one of the more common, and most avoidable, ways adoption quietly stalls.

Is it too late to build buy-in if the tool is already live and adoption is weak?

Rarely. It's more expensive than doing it during evaluation, but the mechanism is the same: give the team real influence over something concrete, even after launch, like a configuration change or a vote in the next rollout wave. Buy-in built late is still buy-in. It's just a harder sell to the calendar.

Buy-in is built, not announced

The instinct to treat buy-in as a launch-week communications problem is understandable. It's also backwards. By the time there's an announcement to make, the people who'll use the tool have already formed an opinion about whether they mattered in getting there, and no rollout deck changes that after the fact.

Bring the daily users into requirements, not just the rollout plan. Give the pilot group one real decision and let them see it stick. Name the rollout owner before the contract, not after. Measure usage from week one instead of the quarterly review. And when a stall at month three turns out to be the team correctly telling you the tool doesn't fit, believe them. That's not a change-management failure. It's the evaluation working exactly as it was supposed to, just later than anyone wanted to hear it.

About the author

Calvin D.

Calvin D.

Head of Enterprise Solutions

Calvin D. is Head of Enterprise Solutions at Rework, with 5+ years and 40+ enterprise engagements spanning 20 to 500+ user deployments. Calvin helps Heads of Operations, IT Directors, and VPs connect CRM, workflow automation, and data into one stack that actually fits together. Readers get field-tested architecture decisions they can apply as their teams scale.

View full profile LinkedIn