A process absent from a CRM may already be supported elsewhere. Identify the decision, required event-level information, source system, data granularity and decision owner before specifying new objects or integrations.
A technically complete implementation can still describe only part of the business
Imagine a supplier of industrial equipment. A CRM implementation records leads, customers, quotes, deals and contract values. The project is correctly delivered: stages work, permissions are configured, reporting is consistent and salespeople can use the system. Yet the business earns additional revenue from planned maintenance and reactive service work. The sales pipeline may tell management what was sold without saying what it costs to fulfil each contract.
That is not proof that the CRM was badly implemented. It is evidence that the project boundary and the business boundary are different. The first question is not how to extend the CRM. It is what decisions the company needs to make about the service operation and what information those decisions require.
Four states behind an apparent data gap
| State | What it means | Implication |
|---|---|---|
| Unknown to the researcher | The information may exist, but the initial project record does not establish where. | Ask where it lives before proposing a solution. |
| Recorded elsewhere | An ERP, field-service tool or spreadsheet captures the event at adequate granularity. | Assess whether any cross-system decision actually requires access or integration. |
| Recorded at the wrong grain | Finance reports monthly labour cost, but management wants profitability for individual jobs. | Determine what operational events need to be captured, by whom and when. |
| Recorded and available, not acted upon | The relevant data exist and can be accessed, but no decision owner or rule uses them. | A software project may have little effect without changing the decision process. |
The same absence on a CRM screen can correspond to all four states. That is why a missing object is not itself an Intervention Candidate.
Define the decision before its data requirements
Suppose a service director needs to decide whether to accept another maintenance contract. They may need to know committed engineer capacity, contractual response times, equipment locations and expected job duration. The required information is not simply "resource data". Each item has a grain, timing requirement and responsible source.
- Decision: accept, reject or reprice a contract.
- Decision point: before making a binding commitment.
- Inputs: available hours by required skill and location, existing obligations, expected service frequency.
- Source events: bookings, work orders, engineer assignments, contract entitlements.
- Ownership: who records each event, and who is permitted to change the commitment?
Only then can the provider evaluate whether the right response is a custom CRM object, a field-service system, an integration, a revised handover or no new software.
Separate information ownership from decision authority
Suppose Sales wants to know real service capacity before promising a start date. Service owns schedules, and Finance owns actual labour cost. Joining systems may improve visibility, but it does not automatically give Sales authority to allocate resources. If the missing element is a decision right or escalation rule, technical integration addresses only one part of the problem.
Business-to-system mapping therefore needs two boundaries: where information is generated and where responsibility for the decision sits. A system map without decision rights can be detailed and still fail to explain the operational constraint.
Conditions that justify investigating a technical change
A technology intervention becomes plausible when there is an important decision or operational commitment, a demonstrable gap in current support, an appropriate technical mechanism and a credible reason to expect the mechanism to change the outcome. The existence of a platform capability does not satisfy those conditions.
Useful next question: Which material decision cannot be made at the right time, using the information and authority currently available?
For the next step, read when an operational entity belongs inside HubSpot and when it may need another system, or inspect a worked illustrative intervention assessment.
Reference context: HubSpot data model documentation; Microsoft Dynamics 365 Field Service documentation. The decision framework and worked examples above are analytical illustrations, not findings from a client engagement.
Related method: Decision-specific data quality
Structural customer attributes are not just CRM enrichment
A customer record can include industry and contact activity while omitting the operational attributes that determine what service can actually be delivered: number of active locations, installed assets, service coverage, approval authority or the customer’s own operating model. The appropriate set is business-specific. Each attribute should be justified by a decision, an accountable owner and a defined update event. Capturing a value merely because it might support future analytics is not a sufficient requirement.
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.