Define the result in everyday terms
Choose a result such as knowing who owns every open enquiry, seeing the next action on a proposal, or handing a confirmed sale to delivery with its agreed scope. Describe the current problem and how people will recognise an improvement. Avoid beginning with a list of screens: the result should remain useful even if the configuration changes.
Name the people and the decisions
Give the rollout an accountable business owner and involve the people who enter information, use reports and support customers. Agree who can change stages, merge duplicate records and approve access. Record decisions about required fields, customer naming, document handling and exceptions in a short working guide.
Test a whole journey
Use a small set of representative records, including awkward cases: two contacts at one organisation, a revised proposal, an incomplete address and a customer with more than one project. Test what happens when ownership changes or information is corrected. Confirm permissions using different roles rather than checking every screen as an administrator.
Launch with support and a review date
Prepare short role-specific guidance and identify where questions should go. Review the first completed journeys with users. Separate training issues from configuration gaps, then prioritise changes by their effect on customer work. Add more modules when the initial records, responsibilities and handovers are dependable.
