Rolling out new software in a DMC: change management comes first

In short. In a DMC (destination management company), a new ERP isn't installed, it's adopted. Adoption rests on four steps: share the why, start from your team's pain points, let them take part in the choice, then manage the switch with internal champions and a switch-off date you actually keep. The software matters. Change management decides the outcome.

I've run Mexikoo, a DMC in Mexico, for over ten years, and I founded Odys, software built for DMCs. So I've lived this from both sides: the owner who wants to change tools and faces a team that doesn't, and the vendor walking agencies through onboarding. Here's what I've learned: switching your ERP is a change management project, not an IT project.

A quick note on words. In a DMC, when I say ERP, I mean the tool where your quotes, supplier bookings, live files and invoicing live. Whatever the brochure calls it.

Why do teams resist a new ERP?

Because people prefer what they know, even when the alternative is better. In 1988, economists William Samuelson and Richard Zeckhauser gave it a name: status quo bias. In their experiments, an option became far more popular the moment it was framed as the current one.

In a DMC, that bias weighs even more. Your ERP is your operations team's second pair of hands. They live in it all day: a quote, a hotel confirmation, a rebooked flight, a roadbook to send. Changing tools means asking them to become beginners again at the thing they do best, mid-season, with travelers on the ground. That's not bad will. It's real discomfort, and it deserves to be treated that way.

The numbers point the same way. In Prosci's Best Practices in Change Management research (2,600+ practitioners surveyed), 88% of projects with excellent change management met or exceeded their objectives, versus 13% with poor change management. It's self-reported and correlational, not proof of causation. But the gap is wide enough to stop treating people as the last line of the project plan.

Why start with the why, before the software?

Because a team that understands where the company is going follows you much more easily on the how and the what. Open with a software demo and you're talking about screens. Open with your vision of tomorrow's DMC and you're talking about their future.

At Mexikoo, I faced real pushback when I wanted to bring in new tools. What unblocked it wasn't a better demo. It was presenting to the whole team, several times, the DMC I wanted us to become: an agency ahead of the curve, where technology is part of the culture rather than a one-off project. And above all, what their roles would become in that DMC.

That's the part a lot of owners skip. Your team spends a big share of its time on logistics: re-entering, chasing, checking, copying. If the tool absorbs part of that, everyone's quiet question is "so what happens to me?" Answer it before anyone asks. Help each person picture a role beyond today's tasks: more time with travelers, more product design, deeper partner relationships. A why that says nothing about their place in the future is just a management speech.

How do you start from your team's pain points?

Ask one simple question. I call it the magic wand question: "If you had a magic wand, what would you never want to do again in your day?"

The answers are concrete and often surprising: typing the same file into three spreadsheets, chasing suppliers by hand, hunting for the latest rate, rebuilding the roadbook from scratch after every change. That's your real list of selection criteria, far more useful than a feature comparison.

Here's how to run it:

1. Collect answers one person at a time, not in a group meeting where the loudest voices take over.
2. Group them into a short list of priority pain points, a dozen at most, in their own words.
3. During vendor demos, have those pain points replayed on real cases from your agency, ideally by the people who raised them.
4. Have the team confirm the tool actually solves those pains, not problems they don't have.

If your team doesn't feel you're solving a pain that's theirs, they won't switch. Software that fixes the owner's problems but not the ops agent's gets worked around, and Excel creeps back in.

Should your team be involved in choosing the software?

Yes, and as early as possible. A manager who picks alone the tool the whole team will use eight hours a day starts with a serious handicap. People rarely reject a tool they helped choose.

This isn't just founder intuition. In 1948, Lester Coch and John French studied changes in work methods at Harwood Manufacturing, a textile plant in Virginia (original study). The group that was simply told about the change saw productivity drop to about two-thirds of its level for a month, with around 17% quitting within forty days. The groups involved in designing the change recovered within days, then ended up about 14% above their previous level, with no one quitting. The study has its methodological critics, but its core lesson has held up for decades: resistance depends heavily on how change is introduced.

In practice, bring at least one person from each function (sales, operations, finance) into the shortlist, the demos and the final choice. And be upfront about what's actually open. If the budget and the switch-off date are set by management, say so from day one. What should be genuinely open is the choice between shortlisted options and how you'll work inside the tool. Fake consultation, where the decision was already made, does more damage than none at all.

What role do internal champions play in ERP adoption?

A champion keeps the tool alive day to day when the vendor's support isn't available right that minute. In a small DMC, one is enough. In a bigger team, plan for two.

Pick people who are a bit tech-minded and respected by their colleagues, and give them a real mandate:

• driving adoption written into their role and objectives, ideally into their variable pay;
• protected time during the first months, not on top of their usual workload;
• a direct line to the vendor to escalate blockers.

Their value comes from something no external support can offer: they know how you operate. When an agent gets stuck, the champion doesn't give the manual's answer, they give the answer that works in your agency. That's what stops the small workarounds that, added up, kill adoption.

How do you switch from the old tool to the new one?

Set an end date, then keep it. At Odys, what I see in most onboardings is that the fastest ones are where the old tool gets switched off: a contract ending, a license expiring. Nobody wants to pay for two tools at once, so everyone speeds up.

The lesson is to recreate that urgency even when nothing forces you to. Your old tool is free, or it's a homemade Excel? Give it an end date anyway. Without a clear date, stated and shared with the whole team, the switch never really happens. Human reflex always pulls back to what's comfortable.

You've got two levers.

The stick: switch off the old tool

You set a date, you announce it, and on that day the old tool goes read-only or disappears. It works, and it's healthy. But used alone, it's a constraint, and a constrained team does the minimum.

The carrot: an adoption bonus

This is the one I prefer, because it makes the move voluntary. You create a one-off bonus, within variable pay or on top of it, for everyone who has switched by a set date.

The trap is picking the wrong criterion. Pay per file created in the tool and you'll get files, not necessarily real usage. That's Goodhart's law: when a measure becomes a target, it stops being a good measure. A well-built bonus follows three rules:

1. It rewards a share, not a volume: 100% of new quotes and new live files created in the new tool from the set date.
2. It's time-limited and announced as exceptional, so it doesn't become an entitlement.
3. It lines up with the switch-off date: the carrot moves the majority, the stick covers the last holdouts.

The carrot gets everyone pulling in the same direction. The stick is the safety net. Together, they turn an announced switch into a real one.

The four steps of the switch, in short

1. The why: your vision of tomorrow's DMC and everyone's place in it.
2. The pain: the magic wand question, then demos run on their own cases.
3. The shared decision: the team takes part in the choice, with clear ground rules.
4. The switch: mandated champions, an end date you keep, and a bonus tied to share of usage.

FAQ

How long does it take to get a new ERP adopted in a DMC?

It depends on file volume and team size, but the most decisive factor is whether the old tool has an end date. Without one, adoption drags on indefinitely.

Who should be involved in choosing DMC software?

At least one person from each function that will use the tool daily: sales, operations, finance. They join demos run on real agency cases and confirm the tool solves their priority pain points.

How do you handle an employee who refuses to use the new tool?

Start by understanding their pain: refusal often signals a poorly covered use case or a fear of losing competence. Pair them with the internal champion. If resistance persists past the end date, the date applies to everyone, no exceptions.

Do you need a bonus to get new software adopted?

It's not mandatory, but it's an effective accelerator if it's well built: it rewards the share of new files created in the tool rather than a volume, it's time-limited, and it coincides with the old tool's switch-off date.

What is an internal champion?

A go-to person for the tool, a bit tech-minded, whose objectives include supporting colleagues and unblocking day-to-day usage in a way that fits how the agency actually operates.

In a DMC, your ERP isn't just another piece of software. It's the tool your team will work with every day, for better or for worse. Choose it with them. The software, honestly, is the easy part.