Enterprise system
CRM and customer operations
Connect customer records, channels, commitments, service and operational execution.
Page purpose
Define the responsibility and boundary of CRM and customer operations before choosing extension, integration or replacement.
A CRM should govern agreed customer, contact, interaction, opportunity, and service-case records without pretending to own fulfillment, invoices, or product usage held elsewhere. The boundary must separate relationship context from legal-party, order, finance, and operational records.
The pivotal decision is whether identity resolution and journey handoffs can become dependable without disturbing a sound relationship lifecycle. Evidence from duplicate resolution, consent scope, pipeline discipline, service routing, and integration failure shows whether configuration is sufficient, selected journeys need a separate orchestration layer, or a CRM capability has reached its limit.
Failure modes
How system failures surface in real work.
- Duplicate accounts and contacts prevent a dependable view of the customer, household, or organization.
- Sales commitments are re-entered into order and delivery systems, losing terms, ownership, and status.
- Service cases lack asset, order, entitlement, or billing context needed for resolution.
System boundary
What the system owns and what remains outside it.
- Which customer attributes and interactions are authoritative in CRM, master data, commerce, service, or finance?
- Can the existing relationship lifecycle support the required identity, workflow, and integration behavior without duplicating customer authority?
- Which journeys need shared global rules and which require controlled business-unit or channel variation?
Target state
Clearer responsibilities and a target operating state.
- A defined customer record with governed matching, survivorship, and stewardship rules.
- Traceable handoffs from lead and opportunity to contract, order, fulfillment, billing, and service.
- Channel and service workflows that use operational truth without copying entire source systems.
System design
Models and contracts specific to the system boundary.
- Customer-domain and CRM record-boundary model.
- Journey and handoff maps for acquisition, sales, onboarding, service, retention, and complaints.
- Integration contracts for parties, products, prices, orders, assets, invoices, and case status.
- CRM capability roadmap tied to identity remediation, journey gaps, integration evidence, and lifecycle constraints.
Transition
Changing the system while operations continue.
- Define customer identities, relationship roles, and authoritative attributes across CRM and adjacent systems.
- Follow real commitments and cases across channel, commercial, fulfillment, finance, and service boundaries.
- Separate configurable CRM behavior from differentiated journeys that warrant governed extensions.
- Release journeys incrementally with duplicate management, synchronization, and queue-operating controls.
Record and operating integrity
Protecting record integrity and continuity during transition.
- Calling CRM a single customer view while unresolved identities and conflicting sources remain.
- Over-automating pipeline or service decisions without usable exception and reassignment paths.
- Synchronizing excessive customer data and creating unclear deletion, correction, and access responsibilities.
System measures
Measures that reveal improvement in real work.
- Duplicate rate and percentage of customer records with an assigned steward and resolved source.
- Handoff completion and reconciliation from opportunity through order, delivery, invoice, and service.
- Case age, reassignment, reopen rate, and availability of required operational context at first handling.
Decision questions
System decisions a product alone cannot answer.
Should CRM become the master for every customer field?
Ownership should follow the meaning of each attribute. CRM may govern relationship and interaction fields while legal identity, orders, invoices, assets, or usage remain authoritative in other domains.
What evidence favors improving the current CRM?
A sound relationship record and lifecycle favor improving the current platform when the real gaps are differentiated journeys or integrations that can change without duplicating customer authority.