Not Every Deal Is Worth Signing: How Restaurant SaaS Companies Should Choose Customers Abroad

A note before we begin: My previous article explored how to screen localisation requests by separating market-entry requirements, local workflows and one-off customer customisation. That article was about screening requests. This one takes a step back. Many SaaS companies do not struggle overseas because they screen requests poorly. They struggle because they chose the wrong customer in the first place. Signing the wrong deal can cost far more than walking away from it.

The big deal that everyone regrets six months later

If you work in overseas markets, you will recognise this moment.

Sales arrives with a major customer. The contract is ten times the size of a normal deal. The whole team celebrates.

Six months later, the deal looks very different:

The customer calls itself a “strategic account” and expects every release to prioritise its custom requirements.
Half the engineering team is maintaining its dedicated branch while the shared roadmap slips into next year.
The customer remains dissatisfied because sales promised capabilities the product did not yet have.
Worse still, the customer refuses to become a reference: “We prefer to keep a low profile.”

This is not just a hypothetical story. Many restaurant SaaS teams have fallen into the same trap.

It has made me increasingly certain of one thing:

The most underestimated capability in taking restaurant SaaS abroad is not winning customers. It is deciding which customers are worth serving.

The localisation article was about protecting product boundaries. This one is about protecting customer boundaries.

Why customer selection is harder than it looks

Most teams focus on how to enter a market: which country to choose, how much to localise, and how to handle payments and compliance.

Far fewer ask which customers they should enter the market with.

The reason is simple. In the early stage, every deal can feel like survival. Turning down a customer feels like turning down revenue and growth.

But global expansion magnifies the hidden cost of a poor-fit customer:

Time zones and languages already make communication more expensive.
Local implementation and support often depend on teams that are still being built.
One mismatched customer can tie up the roadmap, support budget and morale of the entire team.

Customer selection is not about being fussy. It is resource allocation. An overseas team with limited capacity should invest in customers that make both the product and the organisation stronger.

Three customers that look attractive but deserve extra scrutiny

These customers are not automatic rejections. They simply require a clearer view of the cost before anyone signs.

1. The enterprise customer: a large deal with no obvious bottom

Large customers are attractive. They can deliver strong ARPU and an impressive case study.

But they often have mature internal processes of their own. Legacy systems must remain. Permissions need to match their organisation. Reporting must follow existing definitions, and the contract may include dedicated service levels.

If these changes can become standard capabilities, an enterprise customer can make the product better. If they only serve that one account, the team has not gained a high-value customer. It has accepted a long-term obligation to maintain a dedicated product version.

The test: Can the custom work required by this deal be reused for other customers? If not, it may be a liability disguised as revenue.

2. The powerful reseller or distributor: a sales opportunity is not market evidence

Restaurant SaaS companies often rely on local resellers when entering a new market. There is nothing wrong with that. The problem begins when a reseller claims to have access to dozens of restaurants and uses that leverage to push the product toward its own version of what the market wants. Headquarters may then mistake the reseller’s judgement for market evidence.

When a reseller says, “Every restaurant here needs this,” the claim may come from one customer currently in negotiation. The proposed product change may simply be the fastest way to close that deal.

The feedback is still worth hearing, but it should be validated with end customers:

How many target restaurants face the same problem?
Would the absence of this capability genuinely block a sale or normal use?
Does the requirement come from a market rule or one company’s internal process?

A reseller can help you reach the market. It cannot replace your own understanding of it.

3. The mismatched customer: they bought the wrong product, but that does not mean you should rebuild it

This is the least obvious category.

The customer buys your product, but your product does not solve its central problem. It wants sophisticated loyalty marketing while your strength is the transaction engine. It needs enterprise chain management while you are strongest at single-outlet efficiency.

Neither side acknowledges the mismatch during the sales process. After launch, the customer says the product is not good enough. You explain that it was never built for this use case. The more the product changes, the more the customer feels something is still missing. The more the team invests, the harder it becomes to admit that the original fit was wrong.

The test: Is the customer’s most urgent problem solved by one of your most mature capabilities? If not, setting an honest boundary now is cheaper than mutual disappointment after launch.

Do not calculate contract value alone. Calculate Customer TCO

Buyers calculate Total Cost of Ownership. SaaS vendors should also calculate the total cost of serving a customer.

At a minimum, Customer TCO includes:

pre-sales solution design, demonstrations and technical assessment;
localisation, integrations and data migration;
installation, configuration, training and go-live support;
ongoing communication across languages and time zones;
testing and version maintenance for dedicated features;
the opportunity cost of delaying the planned product roadmap for one customer.

The final item is the easiest to miss.

If the development team spends a quarter building one customer’s dedicated requirements, it cannot spend the same quarter improving the standard product. That cost does not appear in the project budget, but it is paid by other customers and by future growth.

A high contract value does not automatically make a high-quality customer. The better question is whether the relationship still improves the product and market position after long-term service costs are taken into account.

Five signals that a customer is worth serving

Viewed from the other direction, good-fit customers tend to show five signals.

Market relevance
Does the customer resemble the target segment you actually want to serve? Will serving it well help the team understand the next group of customers?
Product fit
Does the customer’s most important problem sit within the product’s core strengths? Friction is difficult to avoid when the deal depends on your least mature capability.
Reusable requirements
Can the work become a standard feature, configuration, plugin or reusable integration? If every change must remain in a dedicated branch, the maintenance burden remains as well.
Commercial fit
Does the customer accept your pricing and service model? If the deal begins below the reasonable cost of delivery, there will rarely be enough room to serve the customer properly.
Reference value
If the project succeeds, is the customer willing to become a case study, host a visit or recommend you to peers? In the early stage of expansion, a verifiable customer story is more useful than a logo that can appear only in an internal report.

A customer does not need to satisfy all five conditions. But if product fit is weak, the work cannot be reused and service costs remain unclear, the deal should slow down.

Build a reverse ICP as well

ICP stands for Ideal Customer Profile. It describes the type of customer that best fits your product and is most deserving of sales, product and service resources. A normal ICP tells sales whom to pursue. A reverse ICP tells the team when to slow down.

If a customer shows several of the following signals, the deal should go through additional review rather than being promised directly by sales:

Its core requirement sits outside the product roadmap.
The new capability would serve only this one customer.
Revenue does not cover implementation and long-term maintenance.
Every conversation introduces a new condition for signing.
The customer has little market relevance and offers no meaningful reference or channel value.

A reverse ICP is a warning system, not an automatic rejection. The team may still make an exception for market entry or strategic value, but it should record the reason, investment limit and stop conditions.

Ask five questions before signing

Question	What you need to establish	Warning sign
Is this customer representative of the target market?	Whether it helps validate the market	”This is the only customer of its kind in the market”
Is the core requirement on our product roadmap?	Whether current strengths solve the main problem	The deal depends on the product’s least mature capability
Can the new capability be reused?	Whether it can become a standard feature, configuration or plugin	It requires customer-specific logic
Does the revenue cover the long-term cost?	Whether the economics still work after delivery, support and maintenance	Only initial development and first-year revenue have been counted
Can the customer become a market reference?	Whether success can build trust and referrals	The customer will not be public and offers no other strategic value

This table should not become a mechanical scoring system.

Some customers have strategic value that justifies a short-term cost. Some requirements cannot be reused immediately but are necessary for entering a market. The important point is to document the exception: why it is being accepted, how much the team will invest, who approves it, and when further investment stops.

A “strategic customer” without boundaries often leaves little behind except the word strategic.

Saying no is expensive. Saying yes without boundaries costs more

Rejecting a customer means losing visible revenue. It may also disappoint the sales team.

The cost of saying yes to a poor-fit customer without boundaries appears later: implementation cannot keep up, the product team keeps adding features, and by renewal time both sides still believe the other failed to deliver.

Customer selection does not mean rejecting every complex requirement. The team has several alternatives:

adapt the workflow through existing configuration;
keep differences in a plugin or integration layer;
launch in phases and validate the core capability first;
ask a partner to handle non-core work;
charge enough to cover the long-term cost of truly customer-specific requirements.

If none of these options works, tell the customer clearly what cannot be done, why, and whether a more suitable alternative exists.

An ambiguous promise may secure a signature, but it only pushes the problem into implementation and renewal. How do you say no without damaging the relationship? My previous article on AI-assisted communication for global SaaS teams offers a useful approach: separate emotion from substance, explain the boundary professionally, and offer an alternative. An honest refusal can build trust.

Screen the customer first, then screen the request

Read this alongside the article on localisation and customer customisation and two filters emerge:

When an opportunity arrives, decide whether the customer is worth serving for the long term.
When a request arrives, classify it as market entry, local workflow or one-off customer customisation.

If you screen requests but not customers, the team will keep searching for product solutions to a customer mismatch.

If you screen customers but not requests, even the right customer can pull the product away from its roadmap through commitments without boundaries.

Neither decision belongs entirely to sales or product. Contract value, product direction, delivery capability and long-term maintenance cost need to be discussed at the same table.

Conclusion

Restaurant SaaS companies expanding abroad cannot serve everyone.

The right customer is not necessarily the one with the largest contract or the fewest requirements. It should fit the product direction, support a sustainable service model, and deepen the team’s understanding of the market.

The next time an overseas contract looks too attractive to refuse, ask:

Beyond adding revenue, where will signing this customer take the product and the team?

If the answer is unclear, it is fine to slow down.

The loss from rejecting a deal is visible. The cost of signing the wrong one may not appear until several product releases later.

If you are evaluating overseas customers, try this with three current opportunities. Do not compare contract values alone. Put product fit, reusability, delivery cost and reference value on the same page. Some customers that once looked impossible to refuse may look very different after the calculation. You may also revisit localisation request screening and AI communication for global SaaS teams to build a complete framework for avoiding costly expansion mistakes.

Originally published: 2026-08-11