What to define before choosing a CRM

Before choosing a CRM, define how an enquiry should move through your business: who owns it, what happens next, when responsibility changes, and what information management needs. Those decisions give you a practical basis for comparing platforms and testing whether the selected system works.

A product demonstration can show attractive dashboards and useful automation. Your evaluation also needs to establish whether staff can carry out the work, whether handovers are clear, and whether reports describe the same process that the team follows.

Start with these six questions.

1. What needs to work better?

Describe the operating problem in terms that staff recognise. For example:

• Enquiries arrive through several channels and ownership is unclear.
• Follow-ups depend on personal reminders.
• Two teams maintain different versions of the same customer information.
• Management needs to combine several spreadsheets to understand progress.

Choose the first process to address and define its boundaries. Does it begin when an enquiry arrives? Does it end with a sale, a service handover or a renewal? Agree what improvement would look like, such as every active enquiry having an owner and a recorded next action.

This becomes the starting point for scope and acceptance criteria.

2. Who owns each enquiry and the next action?

Assignment rules need to cover both normal work and exceptions. Decide who receives a new enquiry, what happens when that person is unavailable, and who handles records that cannot be assigned automatically.

Separate ownership from activity. A record may belong to an account manager while another colleague carries out a visit or prepares a quotation. The system should make both responsibilities understandable.

For each handover, define what the receiving person needs to know and how they acknowledge responsibility. A change of owner is only part of the handover; the next action and relevant context need to travel with it.

In one CRM engagement, Nebworx configured enquiries to reach different teams according to their source. After an initial visit, responsibility passed to a specialist who continued the follow-up through the same CRM record. That experience gives us a useful question to bring into software evaluation: can the receiving person pick up the work with the context they need?

3. What does each stage mean?

Agree the evidence needed to move an opportunity from one stage to another. Labels such as “Qualified” or “In progress” are not enough if different people interpret them differently.

For a service business, “Quotation sent” might mean that a dated quotation has actually been delivered to the customer. Drafting the quotation would not meet that condition.

Also decide how to handle opportunities that pause, move backwards, close unsuccessfully or reopen. Keep activities distinct from stages: a completed call is an activity, but it does not necessarily mean the opportunity has progressed.

These definitions help staff use the pipeline consistently and give reporting a clear meaning.

4. Which records and fields need to be reliable?

Identify what the system needs to represent: a person, an organisation, an enquiry, an opportunity and the activities associated with them. One customer may have several opportunities, so counting customer records and counting potential sales can answer different questions.

Define the fields staff need to act and management needs to report. Agree the allowed values for shared fields, which system is authoritative, and who can change those definitions.

Where marketing attribution matters, specify how campaign-source information is captured and retained. Decide how to treat missing sources, repeat enquiries and duplicate records. Capturing a campaign label is useful only when the team understands what it represents and how it connects to the outcome being reported.

In that engagement, capturing UTM campaign information made it possible to trace enquiries through to recorded sales conversions—visibility the previous spreadsheet process did not provide. This supported campaign evaluation; it did not, by itself, demonstrate a financial return. The lesson for selection is to test the connection between source information and sales outcomes, as well as the initial capture.

5. Which decisions should reports support?

Start with the management question, then define the measure. Useful questions might include:

• Which active enquiries have no next action?
• Where are opportunities waiting longer than expected?
• Which campaigns generate enquiries that progress to completed sales?
• Which handovers need attention?

For every measure, specify the records counted, the date used, any exclusions and who owns its definition. For a conversion rate, decide whether the denominator is people, enquiries or opportunities, and allow a consistent period for the outcome to occur.

Be clear about update frequency too. A daily management report and a live work queue serve different needs. The required frequency should guide the integration and reporting design.

6. How will you prove the system works?

Turn the agreed process into a small set of acceptance scenarios before selecting the platform. Include an ordinary enquiry, a duplicate, an unavailable owner, a handover and a reopened opportunity.

During evaluation, ask the supplier to demonstrate those scenarios. Trace one enquiry from capture through assignment, follow-up, handover and reporting. Check what staff enter manually, what the system automates, and how exceptions are handled.

Plan for adoption as well as configuration. Identify who tests the system, who trains the team, who resolves launch issues and who maintains fields and reports afterwards. These responsibilities belong in the implementation scope alongside the software features.

Nebworx’s ongoing CRM work includes maintaining picklists and custom fields, avoiding duplicate data sources, aligning sales processes with the CRM and building operational reports. This work continues after launch as the team’s needs change. Agreeing who will maintain the system is part of choosing a workable solution.

Bring a working brief to the software comparison

You do not need every detail settled before speaking with suppliers. You do need enough shared understanding to make their proposals comparable.

A useful starting brief contains the process boundaries, ownership rules, stage definitions, essential data, reporting questions and acceptance scenarios. Use it to evaluate capability, integration effort, implementation responsibilities and ongoing costs together.

Nebworx’s DESIGN work helps clarify the operating process, system and data requirements before an implementation scope is agreed.

If enquiry handling, handovers or reporting are becoming difficult to manage, start a conversation about the part of the process that needs to work better.