A custom CRM is worth considering when a well-understood business process repeatedly breaks at the limits of your current tools. It is a poor starting point when nobody agrees who owns a lead, what a qualified opportunity means or when the next follow-up should happen. Software can make those decisions visible, but it cannot make them for the business.

Before comparing screens or development quotations, write down one complete customer journey. Follow an enquiry from arrival through qualification, proposal, decision and handover. The useful question is where work becomes unclear, duplicated or impossible to track.

1. Map one real enquiry, including the exceptions

Choose a recent enquiry and reconstruct what happened. Which channel brought it in? Who contacted the person? Where were the notes stored? What happened when the assigned employee was unavailable? Did another team need the same information? Include the points where somebody used a spreadsheet, personal message or memory to bridge a gap.

Then write the rule you want the system to enforce. “Improve follow-up” is too vague to build or test. “Every open opportunity has one owner, a next action and a due date; a manager can see overdue actions” describes behaviour that a team can review.

2. Compare three possible solutions

  • Improve the process: a shared stage definition, clear ownership and a simple daily review may solve the immediate problem without replacing software.
  • Configure an existing CRM: test whether custom fields, permissions, automations and supported integrations can complete the actual workflow. Use representative records rather than a polished demonstration.
  • Build a custom CRM: consider this when essential rules, handoffs or interfaces cannot be represented reliably, or when the cost of continued workarounds is substantial.

Write down why the simpler options fail. “We want our logo on the dashboard” is different from “our document approval process requires several roles and a record of each decision.” The second gives a development team a concrete problem to solve.

3. Define the records before the dashboard

A contact, an organisation, an enquiry and a deal are different things. One person may submit several enquiries, and one organisation may have several contacts. Merging these into a single row can make repeat business, reporting and duplicate handling difficult.

Prepare a small data dictionary: field name, purpose, required format, who can edit it and where it comes from. Decide how duplicates will be reviewed, what happens to an employee’s records when they leave and how a correction appears in the activity history. Do this before importing thousands of spreadsheet rows.

4. Design permissions around work

List the actions each role needs: view an assigned enquiry, reassign it, change a stage, export records, approve a discount or edit automation rules. Seeing a page and being allowed to perform every action on it are separate requirements.

For example, a salesperson may need their own pipeline and activity history, while a manager needs team ownership and reassignment. An administrator may manage settings without being the person who approves commercial decisions. Test those boundaries with separate accounts.

5. Start with one complete release

A useful first release could cover enquiry capture, duplicate review, assignment, follow-up, stage changes and handover. Each step should have an owner and a visible result. A small, complete journey is easier to adopt than several attractive modules that still require staff to copy information between them.

Keep later ideas in a separate backlog. Advanced forecasting, extra channels and AI summaries should have an identified user and purpose before entering the first release. A feature belongs in launch scope when its absence prevents the agreed workflow from being completed or controlled.

6. Plan integrations and migration as delivery work

For each connection, identify the system that owns the record, the permitted data exchange and the behaviour when delivery fails. A form submission that reaches the CRM twice should not create two independent enquiries. A failed notification should be visible to an operator who can retry it.

Rehearse migration with a copy of a representative sample. Check record counts, linked contacts, dates, owners and notes. Agree when the old system stops accepting changes, how the final import will be checked and what would trigger a return to the previous process.

7. Agree acceptance checks and ongoing ownership

Ask a real user to complete a normal enquiry and an awkward one: an existing customer, an absent owner, an incomplete phone number or a reopened deal. Confirm that the history and reports explain the outcome without an administrator repairing the data behind the scenes.

Before launch, assign responsibility for backups, access changes, integration accounts, support and future releases. The quotation should make those responsibilities clear alongside development scope. Compare the ongoing work required to operate each option, not only its initial build price.

A short brief you can prepare now

  1. Describe the one workflow you want to improve and its current failure points.
  2. List users, roles, existing systems and the records that must move between them.
  3. Bring anonymised examples of normal cases and exceptions.
  4. Define launch acceptance checks and a baseline, such as overdue follow-ups or unassigned enquiries.
  5. Name the person who can resolve process questions and approve scope.

Use the custom CRM development guide to turn that brief into implementation decisions. If you want GLV to review the fit, share the workflow and the constraints; a clear starting point is more useful than a long feature wish list.