How would we know when a customer needs something else?
A customer adds a site, changes equipment or faces a recurring service issue. Someone in Delivery may notice before Sales does. The useful question is whether the change creates a buying requirement — and who will check.
A signal is an observation. A buying opportunity emerges only when the business understands what changed, whether it creates a problem the customer cares about, and whether that customer is likely to act.
Where changes in customer requirements become visible
Changes in how the customer operates. A new location, higher production volume, a restructure or a different service requirement may change what the customer needs.
Service history. Repeated failures, unusual requests or more frequent urgent call-outs may indicate an emerging requirement — or reveal that the current service is underperforming.
Dates and commitments. Warranty expiry, contract review and equipment replacement schedules tell you when a decision might occur. They do not reveal who will win it.
Buying behaviour. Orders change in volume, frequency or mix. That could reflect demand, procurement policy, stock levels or a competitor. The transaction record alone rarely distinguishes them.
New questions from the customer. A buyer asks about capacity, reporting, integration or support for a different team. The question is worth following up; it is not yet a budget.
Warranty expiry creates a decision point, not a guaranteed sale
For an equipment supplier, the end of the warranty creates a known date. The customer may need to decide how it will maintain the asset afterwards. But the outcome depends on the asset’s condition, its criticality, the service economics and the alternatives available.
A distributor may offer its own support. The customer may use an internal engineer or delay non-essential work. If the supplier simply raises an upsell task for every warranty end date, account managers inherit a list of reminders, not a qualified pipeline.
Better questions are whether the customer has made a maintenance decision, what reliability or downtime risk matters to them, and who owns the budget. The service history can help open that conversation.
Pass service observations to someone who can verify demand
Service engineers should not have to become salespeople. They need a simple way to record factual changes. An account owner can then decide whether a conversation is warranted.
A useful record can be short:
Event. What happened, when, and who observed it?
Customer context. Which asset, site, team or existing commitment is affected?
Hypothesis. What requirement might this create? Mark it as unconfirmed.
Next action. Who will clarify it with the customer, and by when?
Outcome. New need confirmed, deferred, handled elsewhere, no relevant need, or still unknown.
This can sit in the CRM or in a simple shared workflow. The point is that a new observation reaches someone able to act on it and that the result comes back to the original team.
Test signals against confirmed opportunities and orders
Look at past instances. How often did this event precede a genuine buying discussion? How often did it lead to a proposal or an order? Did the commercial response arrive early enough to matter?
Include examples that did not convert. If you review only the wins, every signal will look convincing in hindsight. Watch for more contacts being created without any corresponding improvement in qualified opportunities or account contribution.
Review the definitions periodically with Sales, Service and Finance. Their feedback will show whether the business is detecting demand or simply generating activity.
Assign responsibility for checking each signal
Record the event, its possible implication, the person responsible for verification and the outcome. This allows Sales and Service to improve the signal definition over time.