A useful CRM requirements brief starts with the work a salesperson must complete. A list of features such as “pipeline”, “automation” and “dashboard” is too vague to test. Map the journey from first enquiry to closed sale, name the people responsible, and write an observable acceptance check for each handoff. This guide gives a small UAE sales team a worksheet it can use before comparing vendors or building a custom system.
Write the workflow before the software specification
Interview a person who handles new enquiries, a manager who reviews opportunities, and someone who resolves data errors. Ask each to show one recent, anonymised enquiry: where it arrived, what was captured, who acted, what they needed to know, and where the record became unclear. Use a real process, not an idealised flowchart. Keep personal details out of the planning document.
Draw a short sequence: enquiry received → owner assigned → qualification completed → proposal sent → follow-up due → won or lost. Add exceptions. Does a returning contact create a new lead? Who can change an owner? What happens when a customer messages on WhatsApp after submitting a form? These questions reveal requirements that a generic feature list hides.
Turn each problem into a testable requirement
| Observed work | Requirement | Acceptance check |
|---|---|---|
| Two staff members respond to the same enquiry | One visible record owner and assignment history | Create a test enquiry, change its owner, and confirm both people can see the change |
| A lead is marked qualified with no reason | Qualification fields with an agreed definition | Try to advance a record with a missing required field |
| Follow-ups are forgotten after proposals | Due date and next action on open opportunities | Find all proposals due this week without exporting a spreadsheet |
| Reports combine enquiries with customers | Separate lifecycle stages and stage dates | Count new enquiries and won customers separately for one month |
“Required” does not always mean a field should block staff. If a phone number is unavailable, allow an explicit “not provided” state where appropriate. The goal is reliable information without forcing invented data.
Prioritise the brief
For every item, record the process owner, present workaround, impact if missed, priority, and whether it can be demonstrated in a short trial. Separate must-have workflow requirements from implementation preferences. A fast implementation can still fail if the contact model, permissions, or reporting definitions are wrong. Include the number of current users, expected growth, languages, data locations, and the systems that need to exchange information.
Ask vendors to show the same three scenarios using sample data. Observe the number of clicks and the questions staff ask; do not score only a polished sales demo. Include who will clean and import historical records, who approves field definitions, who trains users, and what happens when a test fails. Use a role-based CRM training plan to test whether staff can complete their real day-one tasks.
Illustrative trial: a UAE B2B supplier
This is a fictional example, not a Megvi client result. A supplier receives requests through a website form, a shared inbox, and WhatsApp. Six salespeople cover different product lines. The current spreadsheet holds company name, contact, requested product, and a free-text status. The team cannot tell whether a repeat enquiry belongs to an existing account.
The brief sets three tests. First, a form submission for an existing company must appear under that company without deleting the earlier opportunity. Second, an owner must be assigned according to product line and a manager must be able to override it with a recorded reason. Third, a weekly report must distinguish new enquiries, qualified opportunities, proposals, and won orders. The team trials those workflows with ten fictional records, including two duplicates and one enquiry without a phone number.
If a candidate system passes a feature checklist but merges two different contacts merely because they share a company, it fails the first test. That finding is more useful than a generic score of “CRM capability: 9/10”. The related CRM data migration guide shows how to prepare the records for such a trial.
What to send when you request a proposal
- A one-page workflow and the exceptions that cause errors today.
- The field and stage definitions, with three acceptance scenarios.
- A sample of anonymised records and a count of records to migrate.
- The systems to connect, permission roles, and reporting questions.
- A named person who can approve process changes and sign off the trial.
Ask the provider to state what is included, what needs custom work, what evidence will prove completion, and what the team must supply. If you are choosing or designing a CRM for a UAE sales process, Megvi’s CRM development service is the next step. Bring your workflow and trial cases so the discussion can focus on the actual sales work.
Method note: worksheet and company example created for this article; reviewed 19 October 2026. No client performance claim is implied.