"We're Heads-Down on the ERP Rollout Until Q3" — The Competing Initiative Stall

You get twenty-two minutes into a good discovery call. The VP is nodding. He's told you about the ticket backlog, he's told you which team owns it, he's even told you what he tried last year. Then you ask about timing and he says it.

"Honestly, we're heads-down on the ERP rollout until Q3. Nothing new is getting funded before that."

And here's the thing that makes this objection different from every other stall you hear: it's almost always true. There really is an ERP rollout. There really is a program board. There really is a CIO who has told every function that discretionary spend is frozen until the thing is live. You are not being handled. You are being told a fact.

Which is exactly why most reps get it wrong. They hear "true" and they hear "go away," and those are not the same sentence.

Why the competing priorities sales objection breaks reps

Every other stall gives you something to push against. "Send me some information" is soft. "We're happy with our current provider" is a claim you can test. "No budget" invites a question about who does have budget. Those all feel like objections, so reps treat them like objections.

A competing initiative doesn't feel like an objection. It feels like a reason. The rep hears a named program with a named quarter attached and their brain files it under legitimate, and the legitimate file is where deals go to die quietly. You say "totally understand, let me circle back in Q3," you set a task in the CRM, and you have just donated two quarters of pipeline to a program that will probably slip anyway.

I've watched reps do this on calls where the prospect was practically begging for help. The buyer describes a problem, describes the pain, describes what it costs them — and then mentions the ERP program, and the rep folds. Not because the buyer pushed. Because the rep gave themselves permission to stop selling.

The move is not to argue. Arguing with a real program makes you look like you weren't listening. The move is to qualify the initiative with the same rigor you'd qualify a deal, because the initiative is the deal now. It's the largest single thing happening in your buyer's world, and you are either attached to it or you are competing with it.

Qualify the program before you respond to it

When someone says "we're heads-down on the ERP rollout," you have been handed a discovery topic, not an exit. Stay in the conversation. Get curious about the program itself. Four questions do most of the work.

What is it, actually?

"ERP rollout" covers everything from a finance module upgrade to a multi-year replatform touching every business unit. Those are completely different situations for you. Ask:

"Help me understand the scope — is this a full replatform or are you doing it in waves by function?"

If it's a wave-based program, there are functions that already went live and functions that haven't started. The ones already live are your target. They are in the post-go-live mess right now and nobody is paying attention to them because the program team has moved on to the next wave.

Who owns it?

Program sponsor, program director, and the steering committee are three different sets of people, and only one of them controls whether an adjacent piece of scope can be added. Ask who the exec sponsor is. Ask whether it's run out of IT or out of the business. A program run out of finance behaves nothing like one run out of the CIO's office.

Also worth asking: is there a systems integrator in the building? If a big SI is running the program, they have a change control process, a scope backlog, and a commercial interest in owning anything adjacent. That's a wall — but it's a wall with a door in it, and the door is usually the client-side program director who's tired of paying SI change requests for things that should be simple.

What's the real go-live date?

Not the date on the slide. The date the program director says out loud when nobody from the steering committee is in the room. Ask it plainly:

"When's the go-live date on the plan — and how confident is the team in it?"

That second half is the whole question. People will tell you. "The plan says June. We're saying June." That pause is your answer.

Has it slipped before?

This is the single highest-yield question in the set, and almost nobody asks it. "Is this the original date, or has it moved?" If the answer is that the date has already moved once, you now know two things. You know that Q3 is not a real number, and you know your buyer knows it too. That shared knowledge is the basis for a much more honest conversation about what happens in the meantime.

None of these questions are aggressive. You are showing interest in the biggest thing on their plate. Buyers rarely resent that. What they resent is a rep who hears "ERP program" and immediately tries to explain why their point solution should jump the queue.

Big programs manufacture the problem you sell

Here's the part reps miss. A transformation program is not a competing priority in the sense of "they're spending attention over there instead of over here." It's a machine that generates the exact conditions your product exists to fix.

Think about what actually happens during a big platform migration. Data gets moved between systems that don't agree on what a customer record looks like. Integrations get built fast and documented never. Two systems run in parallel for months while the cutover happens by region or by business unit. Teams that had one workflow now have two. The people who understood the old system are consumed by the project and unavailable for anything else. Monitoring, reporting and controls that were built around the old stack quietly stop reflecting reality.

If you sell anything in the operations, observability, data quality, workforce, security or customer experience space, you are not competing with the program. You are selling the thing the program is about to break.

So the reframe you're going for is not "our thing is more urgent than your ERP." It's "the ERP program is going to create a specific problem in a specific quarter, and here's who it lands on." That's a different conversation, and it's one the program people are usually happy to have, because the risk register is the one document in a transformation program that everyone reads.

You can say it almost exactly like this:

"Makes sense — I'm not going to try to compete with a program that size. The reason I'd still want twenty minutes is that in the accounts I've worked with, the migration itself creates the problem we solve. Parallel running, reconciliation, the reporting gap between cutover and steady state. If that's already on your risk register, great, I'll get out of your way. If it isn't, I'd rather flag it now than in June."

That is not a pitch. It's an offer to make their risk register better. Notice you gave them an out — "if that's already covered, great" — which is what makes it land as a peer conversation instead of a push.

Play one: become a workstream inside the program

The strongest outcome is that you stop being a separate purchase and become a line inside a program that already has funding and executive air cover. Budget freezes almost never apply to the program itself. The freeze exists so that the program gets the money.

To get there you need three things. You need a named workstream your capability maps to — data migration, cutover readiness, integration, change management, post-go-live support, whatever the program's own language is. You need someone inside the program who benefits from you existing, usually a workstream lead who is behind schedule. And you need your thing to be described in the program's vocabulary, not yours.

That last point is where most reps blow it. If your one-pager says "AI-powered anomaly detection" and the program's plan says "cutover readiness and reconciliation controls," you are invisible to the program governance process no matter how good the product is. Rewrite it. Literally rewrite the deck so the words match the words on the program plan.

The ask that gets you in the room:

"Who owns the cutover readiness workstream? I'd like to spend fifteen minutes with them — not to pitch, but to understand whether what we do overlaps with what they've already got covered. If it doesn't overlap, I'll tell you so."

Play two: sell the pre-go-live problem the program won't solve

Sometimes there is no workstream to attach to. Fine. Then sell the gap that exists between now and go-live, and be explicit that it's a bridge.

This works when the pain is happening today and the program's answer to it is "eventually." Every transformation program has a list of things it will fix later, and the operational people living with those things now are miserable. The program owner has an eighteen-month horizon. The ops manager has a Tuesday.

So find the person whose Tuesday is bad. Ask the program contact: "Between now and go-live, who's carrying the load on this?" Then go talk to that person. Their budget is usually smaller and their approval path is usually shorter, and a limited-scope engagement that ends at go-live is a much easier thing to approve than a strategic platform decision during a spend freeze.

Be honest about the shape of it. "This is a bridge. It runs until your cutover. If the new platform covers it, we're done and we part friends." Buyers trust that. It also, in my experience, tends to be wrong in the buyer's favour — the new platform rarely covers it, and by go-live you're already embedded.

Play three: agree to wait — but price the wait

Sometimes waiting genuinely is the right answer. The program is real, the timing is bad, and pushing would damage the relationship. Fine. Wait. But waiting has to cost them something, and what it costs them is a commitment.

A re-entry point is only real if it has three components. A date, not a quarter. A trigger event, named. And a person who has agreed on a call to talk to you when it happens.

Weak version: "I'll check back in Q3." That is a note in your CRM and nothing in theirs.

Strong version, said out loud on the call:

"Here's what I'd suggest. Your finance module goes live on the 14th of June. Two weeks after cutover you'll know whether the reporting gap I described is real. Can we put the 30th of June in the diary now — thirty minutes, you tell me whether it's a problem, and if it isn't I'll close the file and stop bothering you. And can I keep Priya in the loop, since she's the one who'll feel it first?"

You've now got a date, a trigger, and a second stakeholder. You've also got permission to contact them, which is the part that saves you from the check-in email problem below. And you've given them a genuine off-ramp, which is what makes them agree.

One more thing to lock: what changes between now and then. "Between now and June, is there anything that would make this more urgent?" Sometimes the answer is an audit, a regulatory date, a contract renewal, a merger. Those are your real triggers and they're rarely the ones on the program plan.

What not to do: the three-week check-in

You know the email. "Hi Mark, just checking in to see if anything's changed on your end!" Sent every three weeks for six months, each one slightly more desperate than the last.

Here is what that email actually does. It trains the buyer that your messages contain no information. After the second one, they stop opening. After the fourth, they've built a mental filter with your name on it, and when Q3 finally arrives and you have something real to say, you're in the folder with the rest of the noise. You have spent your credibility on nothing.

If you're going to stay in touch during a wait, every touch has to carry something the buyer didn't have. A note about how a comparable organisation handled the post-cutover reporting gap. A short piece on what breaks in parallel running. An introduction to someone who's been through the same migration with the same SI. If you can't do that, send nothing and honour the date you agreed. Silence plus a kept appointment beats noise plus a forgotten one.

The other thing not to do: don't try to out-urgent the program. "But this is costing you money every day" is true and it doesn't matter. Nobody gets promoted for de-prioritising the CIO's transformation to buy your thing. You are asking someone to take career risk on your behalf, and they won't.

Where this shows up hardest: telco, healthcare, utilities

Some sectors have a multi-year platform program running essentially all the time, which means the competing initiative stall isn't a phase, it's the permanent weather.

In telecom, it's the BSS/OSS replatform, or the network modernisation, or the post-merger systems consolidation. If you're cold calling a Head of Network Ops you will hit this on nearly every conversation, which is why the telco cold call opening has to earn its twenty seconds on the operational problem rather than on the product — because the product conversation is the one that collides with the program. And when you do get into the room, expect scar tissue: a team that has already been through one big platform promise is a hard audience, which is the whole reason the telco demo needs to be built for people who've been burned before.

In healthcare, it's the EHR. Epic, Cerner, a migration between them, or an optimisation phase that follows one. A CMIO will tell you the organisation is heads-down on the EHR and they will be telling the truth — and also, the EHR program is generating clinical workflow problems on every floor of the hospital as it goes. Getting a CMIO or VP of Clinical Operations to give you twenty minutes usually depends on whether you're talking about the program's aftermath rather than around it.

In utilities, it's the asset management platform, the smart meter rollout, the grid modernisation program, or the regulatory submission cycle that governs all three. The good news is that utilities buyers are unusually willing to talk about program timelines because their plans are semi-public. That makes the qualification questions above much easier to ask, and it's why I lean on program and timeline questions early in the energy and utilities discovery call rather than saving them for the end.

Across all three, the pattern is identical. The program is real, the program is late, and the program is creating work that nobody has been assigned to handle.

What I'd do with this next

Go back through your closed-lost and no-decision pipeline from the last four quarters and find every deal where the reason field says something like "timing" or "other priorities." For each one, answer the four qualification questions above from whatever notes you have. You will find that most of them, you can't. You never asked what the program was, who owned it, when it was really due, or whether it had slipped. That's the gap.

Then practise the response until it's boring. The reason reps fold on this objection is not that they don't know the theory — it's that the stall arrives with authority behind it and they haven't said the counter out loud enough times to say it calmly. I built DrillCall because that's a reps problem, not a content problem: you rehearse the competing initiative stall against an AI buyer who names a real program and holds the line, and you keep going until "we're heads-down until Q3" produces a qualification question from you instead of a polite retreat. Ten reps, ten minutes each, and you'll hear the difference on live calls the same week.

The program is real. Your seat at the table is available anyway. Go ask for it.