Sales Transformation
Sales process and CRM alignment: keeping them in step while CRM changes wait
6 mins read
KEY TAKEAWAYS
Keep one approved description of the sales process, with a named owner, and update the CRM to match it.
Ownership and the questions asked in deal reviews can change now. A new meaning for a live stage or field needs an impact check with the CRM owner first.
If the CRM can't hold new evidence yet, use an existing approved record where you can. If you need a separate register, agree it with the process and CRM owners and link it to the opportunity ID.
Write each CRM change request against a process step, with an acceptance test, so the release does what the process needs.
Retire a workaround once the release is tested and the data is reconciled. Stop duplicate entry, and keep read-only history under your normal retention rules.
Sales process and CRM alignment slips when the process changes faster than the platform. To keep them in step, hold one agreed version of the process, make the changes that don't touch the system, and capture any missing evidence in a controlled, agreed way until the release arrives.
That keeps the CRM as the record people trust while the team works to the new process, and it gives the CRM team a clear requirement to build against. This guide covers the gap between an agreed process change and the CRM release that supports it. For the wider design work, see our CRM transformation guide.
What can change before the next CRM release
Some changes need no configuration and can start now. Others look like process changes but affect the system, so they need the CRM owner's view first.
Can usually change now:
Who owns each step and each handover.
The questions managers ask in deal reviews and forecast calls.
How consistently the team applies stage definitions and field meanings that are already approved.
Needs an impact check with the CRM owner first:
A new meaning or exit rule for a live stage. Stage definitions can drive forecast categories, probabilities, reports and automation, and changing them affects comparisons with past data. Our guide to sales process stages covers how to write exit criteria once they are agreed.
A new use for an existing field, for the same reasons.
Needs a CRM release:
New fields, stages or picklists.
Automation, validation rules and approvals.
Permissions, integrations and reports that other teams rely on.
Interim evidence doesn't replace a required field, an approval or an automated control. Those stay in force until a release changes them.
Agree which list each change belongs on before anyone starts work. Salesforce's own admin training makes a related point: find the business problem behind a configuration request, and talk to the people involved, before building anything.
Keep one approved process map
Write the new process down once, give it a named business owner, and treat that document as the version everyone works from. Microsoft's guidance for its business software recommends mapping current processes, giving each one a business stakeholder who owns it and a subject matter expert, and keeping the documentation up to date after go-live as business needs change.
Then map each step against the CRM as it is today, so the gaps are visible. One short block per step is enough. Here is an illustrative example:
Process step: Qualify the opportunity.
Evidence needed: The buyer's agreed problem, their decision process and a named sponsor.
Where it sits in the CRM today: The problem and the sponsor have fields. The decision process has nowhere to go.
Interim capture: An approved note on the opportunity, or the agreed register.
Owner: Sales operations.
Review date: When the release that adds the decision process field is due.
How to keep sales process and CRM alignment between releases
When the process needs evidence the CRM can't hold yet, first check whether an existing approved record can carry it without changing what that record means, such as an opportunity note your team already uses. If not, a small register agreed by the process and CRM owners is one practical option. It is a suggested arrangement, and not a feature of any particular platform. Keep it small:
The opportunity ID, so every entry links back to the CRM record.
Only the missing evidence, and nothing the CRM already holds.
Who added each entry, and where the information came from.
An owner, a review date and the conditions for closing it.
Keep it in a tool your company already approves for customer data, with the same access controls as the CRM, and don't let it become a second forecast. The risk is ending up with two versions of the process. If sellers each keep a private spreadsheet, the real notes end up outside the CRM, nobody can see the full picture and customer data spreads into places it shouldn't be.
Required fields are worth checking too. If a field must be filled in before the evidence exists, look for placeholder values or the same note repeated across records. Either can mean the field is asked for at the wrong point in the process. Merlin5's work on CRM adoption and management routines treats this as a people question as much as a system one.
Write change requests the CRM team can test
Each request should trace back to a step in the process map. Include:
The process step, and what the team does today.
The evidence the process needs.
The existing field, if there is one, and the gap.
Any report, automation or integration it affects.
An acceptance test: what a user should be able to do and see once it is live.
The business owner who will sign it off.
Microsoft's guidance for Dynamics 365 projects follows a similar structure. It links each requirement to the business process it serves, records acceptance criteria and dependencies, and sets priority by business value and risk.
Decide which changes move first
Move first the changes that block a decision or a handover. Examples include a forecast call that can't see the evidence it needs, or a deal that can't pass cleanly to delivery. Requests that only add fields or tidy a report can usually wait.
This is a judgement call, so make it with the process owner and the CRM team together, and record why. If the change is part of a larger programme, our sales transformation roadmap sets out who owns which decision.
Move the interim work into the CRM
When the release is ready, close the gap in a planned way:
Test the release against each acceptance test, using a sample of real records.
Check the reports, automation and integrations that depend on the change.
Move the interim evidence into the CRM, and reconcile it against the original entries.
Once the reconciliation is accepted, confirm the CRM as the place of record, update the process guide and the training, and tell the team the date duplicate entry stops.
Stop new entries in the register, and keep read-only access to it under your company's normal retention rules.
If the release slips or the reconciliation isn't finished, keep the interim arrangement running and set a new review date. A planned date arriving is not a reason to close it on its own.
Salesforce's admin guidance adds a last step worth keeping: watch the results after the change, and adjust if the business problem isn't solved.
The same discipline helps when the process change is a new sales methodology. Our guide to sales methodology rollout covers the people side of that change.
Where Merlin5 fits
Merlin5's sales process and CRM transformation work designs the process first, then makes the CRM enforce it. Its service page lists transformation experience across Salesforce, Dynamics, SAP, Oracle, HubSpot, NetSuite, Monday, Pipedrive and others.
Where to start
Pick one live gap between the process and the CRM.
Agree what it means, who owns it and how the evidence will be captured until the release.
Review it with the CRM team, and add it to their plan with an acceptance test.
Frequently asked questions
Should we wait for the CRM release before changing the process?
Not for everything. Ownership, review questions and how consistently the team applies approved definitions can change now. A new meaning for a live stage or field needs an impact check with the CRM owner first, and anything that changes automation, approvals or reports waits for the release.
Is a spreadsheet acceptable as a temporary fix?
It can be, if it is approved for customer data, agreed with the CRM owner, linked by opportunity ID, limited to the missing evidence and owned. A separate spreadsheet for each seller becomes a second CRM.
Do we need a new CRM to support the new process?
Usually not. Merlin5's view is that most organisations already have a platform that can support a well-designed process, and that the missing piece is usually the process itself.
Sources
Microsoft Learn, "Optimize your business processes with Dynamics 365", Dynamics 365 implementation guide, updated 20 January 2026. https://learn.microsoft.com/en-us/dynamics365/guidance/implementation-guide/process-focused-solution-opportunity-optimization
Microsoft Learn, "Deliverables in the business process catalog as Azure DevOps work items", Dynamics 365 business process guide, updated 13 January 2026. https://learn.microsoft.com/en-us/dynamics365/guidance/business-processes/about-devops-work-items-deliverables
Salesforce Trailhead, "Follow Practical Admin Tips", Strategic Salesforce Administration module. https://trailhead.salesforce.com/content/learn/modules/strategic-salesforce-administration/follow-practical-admin-tips
NEXT STEP
See where your sales process breaks
Merlin5 designs the sales process your CRM is meant to support, then configures the platform to enforce it, with no software licence to sell.
Book A Sales Process Review
WRITTEN BY
Chris Thomas