Start with roles and the actual case journey
List who uses the CRM: adviser, team leader, back office, compliance, support and possibly an external partner. Each sees a different part of a case and needs different actions. Follow one new case from first contact through verification, offer, approval and handover to ongoing service. For every stage name an owner, necessary information, deadline and evidence of completion. Where financial products are involved, specific obligations depend on product and jurisdiction; confirm the workflow with the appropriate specialist. Do not mistake a generic CRM template for a description of the real commercial process. Observe how staff handle a case today before drawing the new screen.
Focus on exceptions too: a change of adviser, duplicate customer, cancelled meeting, incomplete documents, rejected offer and complaint. These often generate the most manual work. Express each requirement as the ability to resolve a real situation rather than a screen name. For example, a team leader can see cases without a next step and reassign them is more testable than an advanced dashboard. Decide what the first launch must include and what can wait, so the system does not open with many untested features. Record which user will confirm that each scenario actually works in practice.
Design the data model with clear ownership
Distinguish a person, organization, opportunity, product, agreement, task and communication. One person may hold several roles and a case may involve several participants. Define deduplication and linking rules without allowing automatic merging to destroy history. For sensitive attributes record source, purpose and retention according to the actual requirements. The NIST Privacy Framework helps teams reason about privacy risk; the applicable legal basis and retention must be reviewed by the accountable person. A sound data model makes an error correctable and the origin of information explainable. Include who may see a field after a case is transferred.
Name which values are authoritative in CRM and which arrive from another system. If back office owns contract status, CRM should not independently overwrite it. For each important field state who may create or correct it, how the change propagates and what happens during conflict. Preserve a link to the original identifier when importing from an older system. Consider imports, audit records and export if the supplier changes. A comprehensible model offers more value than many free-text fields whose meaning differs across teams. Define the minimum data needed for each stage rather than asking staff to complete a whole customer profile at once.
Test permissions on real cases
Separating administrators from ordinary staff is insufficient. An adviser may see only their customers, a leader a whole team and a specialist selected documents. Access may change when a case is transferred or an employee leaves. Create a matrix of roles, data and actions: read, edit, export, assign, approve and delete. Test direct links to another person's case, a large export and API requests outside the user interface. OWASP lists broken object and property authorization among major API risks. A visible menu item is not the access control; the server must enforce the rule on each operation.
Set rules for delegation and exceptional access. Someone may need to handle an urgent case outside their normal portfolio; that calls for limited permission, justification and an audit record. When an employee leaves, open tasks must transfer and access end without erasing communication history. A system administrator does not necessarily need to view sensitive business content. Permission tests should include team moves, linked customers and a user with several roles. Ownership of access rules belongs with the process leaders; implementation must enforce them safely. Review the matrix after organizational changes rather than assuming the original roles stay fixed.
Make workflow support the next action
Every stage should have an entry condition, responsible person, expected result and failure path. Users need to see what prevents completion and who acts next. Tie alerts to genuine obligations; too many notifications hide an important case. State changes should be traceable, especially when they affect a commercial or financial decision. Do not force staff to fill a field they cannot know at that point. Distinguish information required now from information that can follow later, and monitor quality without blocking all work. A case should never disappear into a status with no owner and no next review date.
Automation can create a task when a document arrives, flag inactivity or prepare a communication draft. Make clear when a person must approve the suggestion and how an incorrect action can be repaired. Before launch, measure how long preparation takes today and where time is lost. After the pilot, watch the change and the number of manual corrections. The value of CRM is not the largest number of automatic rules; it is a trustworthy overview that helps people decide and does not hide responsibility inside a script. Keep a way for staff to explain why they overrode an automated result.
Integrations and reporting must share definitions
List connected systems: email, telephony, documents, identity, product catalogue, agreements, accounting and reporting. For each, specify direction, frequency, identifier, source of truth and error path. Importing email is not a complete integration if a message is attached to the wrong customer or permission to display it is unclear. Version API contracts and test duplicate or delayed responses. Include manual imports; they often substitute for a missing link and create an uncontrolled second record. Decide how a failed synchronization appears to the person working on the case, not only in an engineering log.
Start reporting from the decision it should enable. How many cases wait for a customer, internal approval or a partner? How long does each phase take and where do complaints arise? Define each measure and its source or two teams will use the same word for different numbers. Aggregation must not reveal another portfolio to people without access. Provide a route from a dashboard number to particular cases and a way to explain differences from accounting. A dashboard without a metric owner quickly loses trust. Review whether staff act on each report; remove a view that contributes no decision.
Treat migration as a project of its own
Before moving data, identify active, historical and duplicate records and what must be kept. Create field mappings with owners, a rule for missing values and a way to locate the original record. Verify ordinary and difficult cases on a sample. Compare counts, relationships, open tasks and communication history; a successful file import is not enough. Limit or replace sensitive data in testing. Before cutover rehearse backup, restoration and a process for repairing differences found after migration. Specify which old identifiers will remain searchable and how users will find historical evidence after launch.
During transition decide which system is authoritative and who may write. Two manual records diverge quickly. Pilot with a limited user group and observe whether they can finish a real case without bypassing the system. Provide training, concise instructions for exceptions and a support contact. After launch compare data quality, case duration and corrections with the baseline. Turn off the older system only when retention and access to necessary history are satisfied. Record a cutover decision and the conditions that would trigger a return, including how new changes would be handled.
Ask suppliers questions that expose risk
Request a demonstration using your own scenario, not only a general presentation. How will the CRM handle a duplicate customer, changed adviser, restricted document and late status from a partner? Who can change workflow and how are those changes tested? How are data exported and configuration owned? How do incident response, recovery and permission changes work? Record answers as testable pilot requirements. When a supplier claims a feature exists, ask to see it in the role of an ordinary user and a leader. Include a failure case in the demonstration, because polished success paths hide operational gaps.
Compare total cost: licence, implementation, migration, integrations, training, operations and supplier exit. An established product may be better than custom development if it covers the process well; a bespoke system makes sense where a critical journey needs substantial adaptation. EXCOIN can help design and implement, but this checklist does not rule out other solutions. Document the choice alongside open uncertainties. The first stage should verify the riskiest work path and whether the team can actually use the system, not merely confirm a purchase. Keep ownership of your data and accounts regardless of the supplier.
A checklist to approve the first version
Before launch confirm roles, field ownership, access rules, critical workflows, integration contracts, report definitions and the migration plan. Test at least one ordinary and one exceptional case for every role. Verify that direct URLs and APIs cannot bypass permissions. Rehearse backup restoration and loss of a critical integration. Name a person who can stop release. Users must know where to report an incorrect state and how to proceed when a partner does not respond. Write the criteria before the final demonstration so actual work, rather than presentation quality, is measured.
After launch regularly review unresolved cases, manual workarounds, data quality and user experience on specific tasks. Do not implement every requested change immediately; first find whether the problem lies in process, permissions or interface. Keep changes in a versioned plan with an owner and test. A sustainable CRM simplifies work and provides a credible state without making staff maintain another record. The strongest proof is a case that can be picked up, completed and later explained without searching through private email. Use that evidence to decide the next investment.