Software decisions

When should you configure your existing CRM instead of building custom software?

Custom software is justified by a specific unresolved requirement, not by frustration with a current screen. This guide shows how to test native CRM configuration against real work, identify gaps across import and integration paths, and decide whether a small extension is enough before commissioning a larger build.

Published 5 October 20263 min readBy Clear Anvil

Configure your existing CRM first when its supported fields, views, permissions, templates and automation can cover the required process with manageable upkeep. Consider custom software only after testing a concrete remaining gap. A clear comparison needs actual examples and operating responsibilities, not a list of attractive features.

Start by describing what must happen and who decides it. For example: an enquiry becomes a deal only after an account owner confirms the company, service and next action. That requirement is more testable than asking for a smarter CRM or an AI sales assistant.

Test the work across every entry route

Imagine a fictional distributor using a CRM for equipment enquiries. Staff can make a service-location field mandatory when editing deals, yet the imported spreadsheet contains blank locations. The problem is incomplete data reaching a particular stage through another route. It does not automatically justify a separate application.

Check the product's actual behaviour. Pipedrive, for example, documents that required fields do not stop deal progression when fields are updated through imports, bulk edits, API calls, automations or third-party integrations. That is a specific product behaviour to test, not a universal statement about CRMs. A validation step on the import may solve the remaining gap.

Example requirement test for an enquiry workflow
RequirementNative option to examineEvidence needed
Named owner before reviewFields and stage rulesTry an unassigned deal
Location present on importImport mapping and validationImport a blank example
Quote uses current detailsDocument templateGenerate from amended data
Duplicate enquiry is reviewedMatching and merge toolsSubmit a repeated reference

Check the full native option

Ask an administrator to demonstrate the feature in the buyer's actual plan and configuration. Include permissions, limits and the experience of the staff who will use it. A feature available somewhere in the product family is not necessarily included in the current account.

Do not assume an existing feature is configured correctly. A small change to the record model or template may remove a recurring problem. Equally, do not force a complicated workflow into dozens of fragile fields merely to avoid a build. Evaluate the resulting maintenance burden as part of the decision.

Write down the remaining gap

A useful gap statement names the input, the rule, the proposed output and the exception. For example: when an imported enquiry lacks a site address, hold it in a review list and identify the source row rather than creating a pricing-ready deal. This defines a small extension that can be demonstrated.

Avoid broad gaps such as better user experience unless you can show the concrete task that currently fails. Record whether the shortcoming is a missing capability, a configuration issue, unavailable data or a staff-process problem. Software cannot retrieve a location the customer never supplied without a follow-up step.

Compare ownership as well as capability

  • Who can change the field or rule after launch?
  • Can another administrator understand the configuration?
  • What happens when an import or connected tool changes?
  • Where do failed records appear, and who checks them?
  • Can the business export its records and explain the transformation?

A supported native feature may reduce the amount your team must maintain. A custom component can be appropriate where it isolates a difficult requirement cleanly. Neither choice removes the need for an owner and a recovery process when an update fails.

Run a bounded decision pilot

Select ordinary examples and awkward ones: a missing field, duplicate enquiry, changed company name and late attachment. Test configuration first, then prototype only the unsolved part. Compare completion effort, exceptions and staff review quality across both approaches.

A Clear Anvil workflow review should leave you with a tested configuration option, a specific gap register and a proportionate recommendation. If the CRM covers the requirement, use it. If an extension earns its place, build around the existing source records and keep commercial decisions with authorised staff.

Sources and further reading

AI-assisted research and writing, checked against the linked sources. Worked examples are fictional. Product features can change; confirm the details in your own account.

START WITH ONE USEFUL CHANGE

What could your team
spend less time doing?

Tell us about the work, the tools, and the bottleneck. We can explore a focused pilot by email.

jamil@clearanvil.com