Your most important customer wants an exception.

How do you prioritize client projects when near-term business and long-term development depend on the same specialists? A decision-making case from the machinery industry.

Thursday, 4:40 p.m. Your head of sales is standing in your doorway. Your most important customer wants to add a quality inspection step to its packaging line. Technically feasible. Commercially attractive. The customer needs a commitment by tomorrow.

There’s a catch. The four specialists who could take this on are developing your new machine platform. It is designed to replace customer-specific, one-off designs with reusable modules. Fewer variants, less customization, more business with the same engineering team.

The custom solution would tie up all four specialists for an estimated eight weeks. Based on the current schedule, that would push the platform’s market launch back by three months.

You run the company. What’s your answer: accept the order, turn it down, or negotiate terms?

Take a moment to decide before you read on.

‍

Three perspectives on the same order

‍

The next morning, sales, engineering, and service sit down together. The first ten minutes do nothing to make your decision easier.

Sales: “This customer accounts for 18 percent of our revenue. Say no now, and they’ll bring in another supplier.”

A serious concern. Yet there’s no evidence that all of your existing business with this customer is at risk or that turning down the request would have no consequences. Either conclusion would be an assumption. You ask the head of sales to separate the risk to this order from the risk to the broader customer relationship.

Engineering: “An eight-week interruption doesn’t mean an eight-week delay.”

The next platform test has already been scheduled with a pilot customer. Without those specialists, you’ll miss it. Rescheduling would mean waiting for a later slot. Outside support could take on parts of the work, but it would not resolve the immediate bottleneck.

Then you ask about the platform itself. Two pilot customers have expressed interest. There are no firm production orders yet. So the long-term project is no sure bet either.

Service: “The requested quality inspection isn’t all that unusual. Two other customers have asked for something similar.”

The proposed data interface, however, would be a one-off design that requires separate maintenance. The custom request may point to broader demand. Or it may not: three similar requests are not yet solid evidence of a market.

Are you sticking with your initial decision?

‍

Prioritizing customer projects: What needs to be on the table?

‍

This decision calls for a shared assessment of the financial contribution, strategic importance, credible evidence of customer demand, and available engineering capacity. You also need to consider the impact on other initiatives. The central question is: Does the order justify not only the work it requires, but also what has to wait because of it?

So you ask for two scenarios, side by side.

In the first, the customer order takes priority. Alongside revenue and development costs, the assessment includes the later platform launch, postponed pilot tests, and future maintenance of the custom solution. Impacts that are not yet known are identified as uncertainties, not hidden behind seemingly precise numbers.

In the second, the platform stays on schedule. In return, you accept the potential loss of additional business and the risk to the customer relationship. The platform’s expected benefits also deserve scrutiny: how strong is the evidence that other customers will actually buy these modules?

It’s an uncomfortable exercise. The head of sales can no longer rely on the order value alone. The head of engineering can’t simply call the platform “strategic” and leave it at that.

Both need to explain the assumptions behind their recommendations.

‍

Is the special request an exception – or a market signal?

‍

You ask the team to call the customer. Not to explain your internal resource planning, but to understand the need more clearly.

What does the quality inspection need to do in day-to-day operations? Why does the customer need this specific interface? What, exactly, is non negotiable about the deadline?

Perhaps the customer needs the inspection function early but can wait for full data integration. Perhaps an existing interface would work. Or perhaps the full scope is essential and the deadline leaves no room to maneuver.

You cannot assume any of those answers in advance.

Reusability would support the case for the project only if the solution fits the platform’s technical architecture and other customers have sufficiently similar needs. “We’ll definitely be able to sell this again” is not enough.

Equally, dismissing a relevant customer need simply because it is not on the current roadmap would be weak reasoning. After all, the platform is supposed to serve the market, not the plan.

‍

What would you commit to on Friday?

‍

An immediate yes could be reasonable if the expected business value and the importance of the relationship justify the delay. But leadership would also need to explicitly approve the later platform launch.

Turning down the request could be justified if the custom solution ties up too much capacity, offers little potential for reuse, and displaces a more important development project. But sales should not be left to deal with the impact on the customer alone.

A third option would be a limited assessment rather than a commitment to the full development project. Together with the customer, you clarify the required functionality, the interface, and a possible phased approach. That requires a fixed time budget, named owners, and a date for the decision.

Even this assessment consumes engineering capacity. And the customer may reject it because they need a firm delivery commitment now. The middle ground is not acost-free way out.

‍

An exceptions require a second decision

‍

There is no single right answer in this case. One decision, however, would be hard to defend: saying yes to the customer and continuing to plan internally as though nothing had changed.

Anyone approving the custom development must also document which other initiative will be delayed, who is accountable for the consequences, and when the underlying assumptions will be reviewed. Another approval does not double the capacity of those four specialists.

Think back to your first answer. Would you still accept the order if the line directly below your signature read:

"By making this commitment, we are delaying the launch of our new machine platform by three months."

If so, making the exception may be a sound business decision. If not, perhaps the order only looked attractive because you were considering part of the equation.