"We're Mid-Implementation on Something Else — Come Back After Go-Live"

The objection is true, and that is exactly why it works

Most objections are a polite way of saying no. This one usually isn't. When a plant tells you they are eighteen months into an ERP cutover, or a hospital says the Epic build is consuming every clinical informatics resource they have, or a freight brokerage says the new TMS goes live in Q3 and nobody is looking at anything until then, they are telling you the truth. There is a program. It has a steering committee. It has a name and a logo on a slide deck and a countdown clock in somebody's office.

That is what makes it dangerous. A rep hears a real reason, decides it would be pushy to keep going, and books a vague follow-up for "after go-live." Then go-live slips. Then there is stabilization. Then phase two. The rep who accepted the objection at face value has effectively removed themselves from the account for the better part of a year, and when they finally call back, the champion has moved, the budget cycle has turned, and somebody else got in during the freeze.

The reps who do well here are not the ones who bulldoze past it. Bulldozing gets you nowhere, because the constraint is real. The reps who do well are the ones who figure out, in the next four minutes of the call, whether their thing sits behind the implementation in a queue or beside it in a completely different part of the business. Those are two very different situations and they call for two very different plays.

Separate what the implementation actually blocks from what people assume it blocks

When someone says "we're mid-implementation," they are almost never describing a company-wide freeze. They are describing a resource constraint that has become a cultural one.

Here is what a large system implementation genuinely consumes. It eats IT capacity, first and worst. Integration developers, data migration people, the small number of internal folks who actually understand how the old system's tables are structured. It eats the change management budget, meaning the org's willingness to ask frontline staff to learn one more new thing. It eats leadership attention at the steering committee level, because the CIO is presenting status to the board and does not want a second variable. And it often eats a genuine line item, because these programs are expensive enough that other capital requests get deferred until the number is known.

Here is what it does not consume. It does not stop a maintenance manager from having a reliability problem that the new ERP was never going to solve. It does not stop a VP of clinical operations from missing her throughput targets. It does not stop the brokerage's carrier sales team from struggling to source capacity on lanes the new TMS will route but not fill. It does not stop the safety incident, the turnover problem, the compliance deadline, the customer who is threatening to leave.

The implementation is a project. The business is still a business. Somebody in that building is still accountable for a number this quarter, and that number does not get a grace period because IT is busy.

So the real question is not "how do I get past this objection." It is "whose problem am I solving, and does that person's problem have anything to do with the program that is eating everyone's calendar?" If your product needs three weeks of integration work and a data feed from the very system being replaced, you are in the queue and you should stop pretending otherwise. If your product is bought by an operating leader, deployed without touching the core system, and solves something the new platform explicitly does not address, you are adjacent, and adjacent deals close during freezes all the time.

I have sold inside two large technology companies and I have started and exited four businesses of my own, and the pattern held in both worlds. The freeze is real for infrastructure. The freeze is soft for anything that makes a line manager's month better without asking IT for a thing.

The two questions that tell you which one you are

You do not need a discovery framework here. You need two questions, asked conversationally, right after they raise the objection. Do not argue first. Acknowledge, then ask.

Question one: "Totally fair. Just so I understand the scope — is the freeze on anything that touches the new system, or on new spend generally?"

This is the single most useful question in the whole conversation and almost nobody asks it. The answer tells you which door is closed. If they say "anything that touches it," you have permission to explore whether you touch it. If they say "honestly, all new spend is getting scrutinized right now," you are in a budget conversation, not a capacity conversation, and that is a different play entirely. If they say "IT is slammed but the business units are still buying their own tools," you have just been handed the map.

Most people answer this honestly because it is a factual question about their own environment, not a sales question. It does not feel like you are pushing. It feels like you are trying not to waste their time, which is exactly what you are doing.

Question two: "What is the new system explicitly not going to fix that is still on your plate?"

This is the one that opens things up. Every implementation has a scope document, and every scope document has a set of things that got cut, deferred to phase two, or were never in scope at all. The people living with the program know that list better than anyone, and they are often frustrated by it. Asking about it positions you as someone who understands how these projects actually work rather than someone trying to sell around them.

I have heard answers to that question that turned a dead call into a sixty-day cycle. A maintenance leader at a plant told me the ERP was going to give finance beautiful work order costing and would do absolutely nothing about the fact that his techs were still writing condition notes on paper. A hospital operations leader said the EHR migration was going to standardize documentation and would not touch patient flow between the ED and the floors, which was the thing her CEO asked about every Monday. Neither of those was blocked by the program. Both were made more urgent by it, because the program had raised expectations that something was finally going to get better and had simultaneously locked up every other improvement effort for a year.

If you sell into plants, the structure of that whole conversation — what a plant manager owns versus what a maintenance leader owns, and how to get at the gap between them — is worth practicing before you need it, and I have written up how I run those calls in the manufacturing discovery playbook. The equivalent logic for clinical buyers, who will hedge harder and give you less, sits in the healthcare cold call script.

If you are in the queue, say so out loud

Suppose the answers come back badly. You need the integration. You need IT. Your thing genuinely cannot be deployed until the new core is stable. Do not pretend otherwise, and do not try to convert a queue problem into an urgency problem. You will sound like every other vendor who has called them this month.

Instead, do the thing almost nobody does: name it, and then change what you are asking for.

"Then I am not going to try to sell you anything this quarter — you would be right to say no. What I would like instead is fifteen minutes with whoever owns the integration roadmap, so that when you get to the point of listing what plugs into the new platform, we are on the list and not a surprise."

That is a different meeting. It is cheap for them to grant. And it puts you inside the planning process for phase two, which is where the actual decision gets made, rather than outside it hoping to be remembered.

The other move for queued deals is to get your requirements in front of the systems integrator or the internal architect while the design is still fluid. Every one of these programs has a period where the integration patterns are being decided. If your data needs to come out of the new system eventually, it costs nothing to be a known consideration during design and it costs a great deal to be a change request afterward. Frame it that way to your buyer, because that framing is genuinely in their interest and they will recognize it.

Book a dated checkpoint tied to their milestone, not to your quarter

Here is where most reps blow it. They say "great, let me check back in a quarter," the buyer says sure, and both parties understand that nothing has been agreed to.

A quarterly touch is a calendar event for you. It is nothing for them. The alternative is to tie your next conversation to a milestone that already exists in their world.

These programs have a public schedule. There is a cutover weekend. There is a hypercare period, and it has a defined end. There is a phase two kickoff, or a stabilization review, or a post-implementation lessons-learned session. Ask which of those is on the calendar and when, and then anchor to it.

"When does hypercare end?"

"End of March, in theory."

"Then here is what I would suggest. Let's put thirty minutes on the calendar for the second week of April. Not a check-in — a working session on the throughput piece we just talked about, because by then you will know what the new system actually did and did not fix, and I will have something specific to show you. If March slips, you email me and we move it. Does that work?"

Three things are happening in that script. You have given the meeting a purpose that is not "catching up." You have acknowledged that their date will probably move, which builds enormous credibility because everyone knows it will. And you have made it a dated calendar invite rather than a note in your CRM, which means it survives you changing territories and them changing priorities.

Send the invite on the call. Not after. On the call. "I am sending it now, it will land while we are talking." An unsent invite is a maybe.

One more detail. Put the reason in the invite title. Not "Tim / Sarah catch-up." Something like "Post-hypercare: ED-to-floor throughput options." When it surfaces in April, it explains itself to a person who has been underwater for four months and does not remember your name.

Be useful during the freeze, on purpose

The eleven months between now and go-live are not dead time. They are the cheapest relationship-building window you will ever get, because your competitors have all accepted the objection and gone quiet.

What useful looks like is not a monthly "just checking in" email. It is not a case study attachment. Useful means you send things a person in the middle of a painful implementation would actually open.

The most valuable thing you have is pattern recognition across accounts. You have watched other organizations go through the same cutover. You know what breaks in week three. You know that the reporting always comes up short at first and everybody panics and it settles down. You know which parts of the old process people quietly keep doing on spreadsheets. Send that. "You mentioned go-live is in June. The thing I have seen catch people out at that stage is X. Not selling you anything — just thought it was worth flagging."

Introductions are the other currency. If you know somebody at a similar organization who came out the other side of the same platform migration eighteen months ago, offering that connection is worth more than any deck you own. Your buyer will take that call, and they will remember who arranged it.

And during the freeze, keep mapping. Implementations reshuffle org charts. New roles get created — a data governance lead, a systems owner, a process improvement person who did not exist before. The person who owns your problem after go-live is frequently not the person who owned it before. Spend the freeze finding out who that will be. In financial services especially, where a core replacement at a wealth platform tends to redraw who owns which piece of the client experience, the financial services discovery playbook covers how I map those roles before the conversation. Utilities have the same problem on a longer clock, and the energy and utilities playbook works the same way for asset and network buyers.

Do not send more than one genuinely useful thing a month. Frequency without value is just noise, and noise during a freeze is how you get filtered.

What this actually sounds like when it works

The whole exchange takes about ninety seconds, and it goes something like this.

They say: "Look, we are in the middle of a TMS implementation, go-live is in Q3, nobody here is looking at anything new until that is done."

You say: "Makes sense, and I would say the same in your position. Quick question so I know whether to bother you — is that a freeze on anything that touches the new platform, or on new spend across the board?"

They clarify. Say it is the former.

You say: "Good, that helps. Then the other thing I would ask is what the TMS is explicitly not going to fix that is still yours to deal with. Because if the answer is nothing, I will get out of your way."

They tell you. They almost always tell you, because it is on their mind.

You say: "That is the piece we work on, and it does not need anything from your IT team. I am not going to push it while you have a cutover in front of you. What I would like is thirty minutes in the second week of October, after hypercare, on that specific thing. I will send the invite now and if Q3 slips you just move it."

That is it. No pressure, no reframe, no manufactured urgency. You accepted the constraint, tested its boundaries, found the adjacent problem, and left with a dated meeting that has a reason attached. If it turns out you really are in the queue, you leave with a roadmap conversation instead, which is worth more than the meeting you were originally trying to get.

The hard part is not the logic. The hard part is doing it in real time when someone has just given you a perfectly reasonable no and every instinct says be polite and go away. That is a reps-under-pressure problem, not a knowledge problem, which is why I would run this one as a live drill before I ran it on a live account — get someone to throw the mid-implementation objection at you cold, in different flavors, until the two questions come out without you thinking about them. That is precisely the kind of thing we built DrillCall for, and it is the pattern I would practice first if implementation stalls are eating your pipeline.

The accounts sitting inside a cutover right now are the least contested prospects on your list. Everybody else already crossed them off. Go work the window.