How to choose a CRM for a small consulting business

Start with the missed opportunity, not a feature list

A consulting business usually starts with a spreadsheet, an inbox and a founder who remembers every conversation. That arrangement can work. The problem appears when the business becomes dependent on memory: a warm introduction disappears, two colleagues contact the same prospect, or a proposal waits because nobody owns the next step. A CRM is worth considering when it solves one of those observable failures. Buying one simply because the business has grown does not establish what success should look like.

Write down the last five sales opportunities that became difficult to manage. For each, record the failure, its consequence and the information that would have prevented it. “We need better organization” is too vague. “We could not see who last spoke to the finance director” is a useful requirement. This guide offers an evaluation process, not a claim that we have tested every CRM. The examples are hypothetical and the scoring method is an editorial suggestion you can adapt.

Separate relationships from opportunities

A person and a deal are different records. A former client might introduce three prospects without buying another project. A single company might have two separate proposals, each with a different decision maker. If you store all that information as one spreadsheet row, a stage such as “proposal sent” becomes ambiguous. Is it describing the relationship, one engagement or the entire account?

Before looking at software, sketch the objects your business needs: people, companies, opportunities and activities. Then decide which objects need to connect. A solo adviser may mostly need contact history and reminders. A consultancy with several salespeople may need assigned opportunities, stages and next actions. Neither workflow is inherently more mature. The right structure is the one that makes responsibility visible without forcing the team to maintain information it never uses.

Build a short list around your selling motion

folk and Pipedrive are two relevant starting points in our directory. folk provides contact-oriented CRM capabilities and integrations; Pipedrive emphasizes pipelines, deals and activities. That distinction is a starting hypothesis, not a hard boundary: review both products against your requirements rather than assuming one lacks capabilities because of its positioning. See the official folk integrations overview and Pipedrive pipeline documentation.

If referrals and long-term relationships drive most opportunities, start the trial with relationship history. If work repeatedly moves through qualification, proposal and negotiation, start with deal progression. Also include your existing spreadsheet as a candidate. When the main problem is inconsistent follow-up, a clear owner and a weekly review may improve results without a migration. The comparison should establish whether software adds enough value beyond that simpler change.

Define stages that mean something happened

Useful pipeline stages describe evidence, not optimism. “Interested” can mean anything from a polite reply to an approved budget. “Discovery completed” is clearer if it requires a confirmed problem, a named decision maker and an agreed next step. Define an entry condition and an exit condition for each stage. Keep the initial number of stages small enough that a colleague can remember them without a training manual.

For example, a hypothetical consultancy might use inquiry, qualified discussion, scoped proposal, commercial review and decision. A deal should not advance merely because time passed. Record the customer action that justifies the move. Keep stalled and lost reasons separate from stages so that an abandoned proposal does not remain in the active forecast. During a trial, ask two people to classify the same sample opportunities. Disagreement exposes a process problem before it becomes a reporting problem.

Run a trial with awkward records

A polished demo uses clean data. Your trial should include the exceptions that cause work: a contact with two email addresses, a company that changed its name, a former client with a new employer and two live opportunities at the same account. Use synthetic or appropriately permitted information rather than importing your entire customer list immediately. Check duplicate handling, ownership and the path back to the original record after an edit.

Ask a teammate to answer three questions without help: who owns this relationship, what happened last, and what happens next? Time the complete task, including searching and correcting mistakes. Then test a handoff while the usual owner is unavailable. If the record is technically complete but still requires a private explanation, the workflow is not yet sufficient. Adjust the fields before assuming that buying a more expensive plan will fix the problem.

Calculate the cost of keeping the system useful

Seat price is only one part of ownership. Include the people who occasionally need access, required integrations, data cleanup and the weekly maintenance routine. Use current vendor quotes rather than an old pricing table. A hypothetical system costing 120 currency units per month plus two hours of administration at 40 units per hour has a working monthly cost of 200 units. These are illustrative inputs, not vendor prices or a promise of savings.

Compare that cost with a conservative benefit you can observe. If the software saves time, ask whether the saved hours can actually be used for paid work or higher-priority tasks. If the benefit is fewer missed follow-ups, measure completed next actions rather than claiming every recovered conversation becomes revenue. Avoid counting the same benefit twice as both time saved and additional sales. The decision can still be worthwhile when the benefits are operational rather than immediately financial.

Plan the migration and the exit together

Export a backup before cleaning records, and preserve a stable identifier so you can trace a migrated contact to its source. Import a small batch, inspect field mapping and verify that dates, owners and company associations survived. Decide which historical notes matter for future work. Copying years of irrelevant material makes a new system harder to trust and increases the effort required to find useful context.

Also test an export before committing. Ask whether contacts, notes, deal history and attachments can be retrieved in a usable form. Document what would require manual work if you left. Assign a person to maintain field definitions and remove unused fields. Set a review date after the first month with a clear question: are people finding context and completing follow-ups more reliably? An exit plan gives you a practical alternative if adoption never materializes.

Your CRM trial worksheet

Create one page with these headings: failure to fix, required record, owner, task, expected result, observed result and unresolved question. Populate it with five scenarios: a warm introduction, a repeat project, a colleague handoff, a stalled proposal and a duplicate contact. For every scenario, distinguish a product limitation from an unclear internal rule. Mark a requirement as unverified when you have only seen it in a sales presentation.

Use a simple scale: zero means the task failed, one means it required substantial manual work, and two means an ordinary team member completed it independently. Choose weights before the trial. If handoffs are the main problem, give that scenario greater weight than visual customization. Do not use a high average score to excuse a failed mandatory requirement such as permission control or a necessary export.

At the final review, write a short decision rather than a long feature inventory: the workflow we tested, the option that handled it best, the cost assumptions, the remaining risks and the date for reassessment. If neither candidate improves on the spreadsheet plus a disciplined review, keep the simpler system. If a CRM earns its place, expand it gradually after the core workflow is reliable.