Custom CRM development: an acceptance checklist before launch
Approve a custom CRM against written examples of the work it must complete. Each example needs a starting record, a user role, an action and an expected result. Run the examples with realistic test records before importing the full customer database.
Define the first complete customer journey
Start with an enquiry and follow it through assignment, contact, quotation and outcome. Identify who acts at each point. A stage called Follow up needs a responsible person, a due date and a clear rule for what happens when the date passes.
Choose a small set of representative journeys: a new enquiry, an existing customer asking for another service, a duplicate contact and a lost opportunity returning later. Agree which fields are required at each stage. Include the history a manager needs when someone leaves or changes roles.
Turn requirements into observable tests
The table below is a starting acceptance sheet. Replace its example rules with your own business decisions. Keep the actual result and any unresolved defect beside the expected result. A feature name in a proposal provides too little detail to settle a disagreement at handover.
| Test scenario | Expected result to agree |
|---|---|
| The same enquiry arrives twice | One customer record or an explicit review queue, with both source events retained |
| An assigned employee is absent | A manager sees the unattended enquiry and reassigns it with history preserved |
| A quotation changes | The approved version and previous versions remain identifiable |
| A customer declines | The opportunity closes with a reason and agreed future contact treatment |
| An integration retries | The same incoming record does not create repeated work |
| A report is exported | The totals match the chosen records, date range and currency |
Check what each role is allowed to do
Use separate test accounts for sales staff, supervisors and administrators. Test direct record links and exports as well as the normal menus. Decide who is allowed to change ownership, delete records, see financial figures and download the contact database.
Include a departed employee and a customer portal account if those roles exist. Removing access should be part of the operating procedure. Ask for a record of significant changes and administrative actions.
Put the security requirements in the development brief. Ask the supplier to explain how access controls, software updates and vulnerabilities will be handled and checked. NIST's Secure Software Development Framework can help structure that discussion.
Reconcile migrated records and reports
Export a sample from the current system before agreeing the migration price. Inspect contact fields, attachments, notes, open opportunities and historical dates. Record any cleanup decisions so the same rule is applied throughout the import.
Compare counts and selected record contents after migration. Check open pipeline value using the same stage, currency and date rules. A difference might come from duplicate records, missing amounts or a changed reporting definition. Resolve the reason before accepting the new total.
For example, a test set with twelve enquiries, two duplicates and three approved quotations should have an agreed treatment for each record. Those quantities are test inputs. They are unrelated to a forecast of sales improvement.
Agree ownership, running costs and support
The handover should identify source code rights, hosting accounts, domain control, backups, documentation and third-party subscriptions. Establish who pays for email, messaging, storage and any external API. Ask what remains usable if the support agreement ends.
Specify the support hours, incident route and restoration responsibilities. Include a backup recovery exercise in acceptance where business continuity depends on the application. Ask the developer to show how the records are exported in a usable format.
A development quote should attach this acceptance sheet to its scope. When a requirement changes, update the expected result, price and delivery implications together. This gives the buyer and developer the same definition of completion.
Discuss a custom CRM
Tell us about the work you are planning and the result you need.
Discuss a custom CRM