Blank cells in a service-penetration matrix do not demonstrate unmet demand. To identify work worth investigating, examine the client’s operating dependencies, existing system coverage, the decision owner and the provider’s delivery capability.
Limits of a services-by-account matrix
A common account-planning technique puts customers on one axis and services on another. Blank cells are interpreted as expansion potential. That is useful for describing penetration of an existing offer, but a blank cell does not show demand. The customer may already have an adequate system from a different supplier, may have no operational need, or may lack authority or appetite to change.
For implementation and development firms, the services matrix also creates an incentive problem. It begins with what the supplier can sell. Consequently it can frame the account's business around technologies rather than around the decisions and obligations that actually make the company run.
Map dependencies before platform capabilities
Map how the client earns, fulfils obligations and receives payment. Where the business depends on scarce engineers, distributed equipment, regulated records or complex handovers, identify the information and decision points required to operate those processes. Then annotate what the original implementation covered and what may be supported elsewhere.
This is not a full consulting diagnosis of the end client's business. It is a constrained outside-in model used to decide whether a particular unknown warrants a client conversation.
| Business dependency | Possible decision | Question before proposing technology |
|---|---|---|
| Equipment installed at many sites | When and where to service or replace assets | Which system records location, state and service history? |
| Labour-heavy contract delivery | Whether another contract can be delivered profitably | Are actual hours captured per job and linked to the original scope? |
| Multiple routes to market | How to allocate selling effort across segments | Can sales outcomes be linked to the circumstances that preceded demand? |
| Recurring customer commitments | Which renewals need intervention, and when | What event creates a managed renewal decision rather than a calendar reminder? |
Filter by materiality, coverage and delivery fit
- Materiality. Does the potential gap relate to an important economic, operational or compliance decision? Unused software features are not material by default.
- Coverage. Could an existing operational system already meet the need? If so, assess integration only if another decision depends on the same data.
- Provider fit. Is the potential work within the firm's capabilities and a sensible extension of the relationship? If not, do not create a sales thesis for it.
Example: an additional maintenance location
Assume a CRM implementation partner has finished a sales-system rebuild. The client publicly announces a second maintenance depot. An untested expansion thesis might say: “Sell scheduling software.” A disciplined review says: “Multiple depots can change how work is allocated; it is unknown whether scheduling is coordinated already, what the capacity constraint is or whether centralisation is desirable.” The research output is an account question, not a software proposal.
If the client confirms an existing field-service solution that works across depots, the candidate may be closed. If it confirms duplicate records and decisions made from stale data, an integration or master-data investigation may be justified. If it has no reliable record of service work, the first intervention may be in process definition and event capture.
Portfolio analysis: repeated dependencies are not proven demand
Several accounts may show similar dependencies. But apparent repetition is not proof of repeatable demand: the systems, decision rights and customer appetite may differ. Only after candidates are validated can the provider test whether the same capability is genuinely valuable across a segment.
A service not yet sold is a gap in the supplier’s account coverage. An intervention candidate requires a consequential client decision, incomplete or uncertain existing support, and a testable reason to investigate a technical change.
Related: what to investigate between engagements and why candidates should not enter the pipeline prematurely.
Analytical framework and hypothetical examples. The method does not assume access to or endorsement by any named IT implementation partner.
About these notes. ProperBizFix uses business-model and system-coverage analysis to identify questions worth testing with an existing client. Examples are illustrative unless expressly described otherwise. How the research works.