CRM for small business and where to start

A company with six employees is told it needs a CRM, buys one, uses it for a month and quietly goes back to the spreadsheet. That sequence is common enough to be the default outcome, and the reason is almost never the software.

The reason is that the system was bought before the problem it was supposed to solve had been named.

When a CRM is genuinely needed

The honest test is not the size of the company. It is whether things are being lost.

• Inquiries arrive through several channels. Phone, email, messaging apps, the site form.
• More than one person handles them. Nobody is sure who took which.
• The deal takes more than a day. There is a middle to keep track of.
• Follow-up is part of the process. Somebody has to come back later.
• The owner cannot see the pipeline. Only the result at the end of the month.

Two or three of those together usually justify a CRM. One on its own rarely does.

The clearest single symptom is a customer who says they wrote last week and nobody replied. If that has happened more than once, inquiries are being lost somewhere between the channel and the person, and a spreadsheet will not fix it because the spreadsheet is only opened when somebody remembers to open it.

What a CRM does and what it does not

The expectation gap here causes most of the disappointment.

A CRM records. It holds every inquiry in one place with a status, a history and an owner, and it reminds somebody when a step is due. That is the whole mechanism, and it is a valuable one.

What it does not do is sell. It will not improve a weak offer, speed up a slow salesperson or generate demand that does not exist. A company with no inquiries that installs a CRM has an organized absence of inquiries.

It also does not run itself. Every field that somebody must fill in is work, and a tool configured to demand twenty fields per contact will be abandoned within a fortnight. That failure mode and several others are examined in our article on why CRM rollouts fail most often.

Three problems people usually start with

Not losing inquiries

This is the first and most valuable thing to solve, and it is solvable on its own before anything else is configured.

Every channel is connected so that an inquiry creates a record automatically. The site form, the phone, the messaging app, the mailbox. Nothing depends on somebody remembering to write it down, because that is precisely the step that fails.

Five questions are enough to test a candidate on this side of things.

• Where your inquiries arrive. List your own channels before looking at systems.
• Whether an integration exists. Or connecting becomes a separate order.
• What connecting costs. Sometimes more than a year of the subscription.
• What happens if a channel changes. Messaging apps change more often than expected.
• Who notices when the exchange breaks. It breaks quietly, with no error message.

Those questions rule out part of the shortlist before any demonstration. A system that cannot accept your main channel does not fit, however convenient it is elsewhere. When no ready module exists for that channel, connecting it is custom web development, and it is worth pricing before the subscription rather than after.

At the end of a week, the number of records should match the number of real inquiries. When it does not, the gap shows exactly which channel is not connected properly, and that is worth knowing regardless of what else the system is used for.

Seeing the state of deals

The second problem is that the owner cannot tell what is in progress without asking each person individually.

A pipeline with a handful of stages solves it. New, in discussion, quoted, agreed, done. Five stages is usually enough for a small company, and adding more before the first five are being used consistently makes the system harder without making it more useful.

What this gives is not a report but an early warning. A deal that has sat at the same stage for three weeks is visible on the board, and it is visible to the owner rather than only to the person who has stopped chasing it.

Not losing existing customers

The third problem is the least urgent and the most profitable to fix.

Most small businesses have customers who bought once and were never contacted again, not out of neglect but because nobody had a list. A system that holds the history makes that list exist, and a deliberate reason to make contact, such as a service interval or an annual renewal, turns it into repeat sales, which cost far less than winning a new customer.

A ready system, a set of connected services, or something built for you

There are three routes and they suit different situations.

A ready-made product is the default and the right answer for most small companies. It is available immediately, it is paid monthly, somebody else maintains it, and it covers nearly everything a typical business needs. Its limitation is that you adapt to it rather than the other way round.

A set of connected services means using several apps you already have and joining them with an automation layer. It suits very small teams with an unusual process, it is cheap to start, and it becomes fragile as the number of connections grows, because each one is a point of failure that nobody owns.

Something built for you is justified when the process genuinely does not fit anything on the market, when the business has a workflow that is its own advantage, or when data cannot leave your own infrastructure. It costs more up front and removes the monthly fee per user, which matters as the team grows. The full comparison, with the numbers, is in our article on choosing between an off-the-shelf CRM and a custom system.

The mistake here is choosing the third option first. Almost every business that ends up commissioning its own got there after using a ready-made one long enough to know exactly what was missing, and that knowledge is what makes the build succeed. When that point comes, we build a CRM around your process as part of web application development.

What to compare options on

The feature lists are all similar and all long. These are the parameters that actually differ.

There are also questions that are not in any comparison table and decide more than the table does.

• How long it takes a new person to learn it. It should be hours, not days.
• How long it takes to enter one deal. If it is more than a minute, managers will quietly stop entering deals.
• Whether it works properly on a phone. For anyone who is not at a desk.
• What support is like in your language. And within what hours.
• How often the interface changes. Frequent redesigns retrain your staff for you.
• Whether the vendor is likely to still exist. Small tools disappear.

The export line is the one people skip and regret. A vendor who makes it awkward to take your customer list out has made a deliberate choice about that, and you find out at the worst moment.

Price per user is the line that changes with time rather than at purchase. A figure that looks trivial for four people looks different for twelve, and the tier structure is usually arranged so that the features a growing team needs sit one level up.

What it costs

A ready-made product is a monthly fee per user, and for a small team that is a modest and predictable line.

Getting it set up properly is the part that is usually underestimated. Connecting the channels, defining the stages, importing the existing data and training the staff is a project of its own, and doing it badly is why the system gets abandoned.

Integrations and custom modules built for your process cost from $500 to $2,000. That covers connecting a ready product to your site and your other apps, which is the most common request, rather than building one from nothing. Two-way sync with your accounting system and complex business logic cost from $3,000 to $8,000.

Where to actually start

The order matters more than the choice of product, and it is the reverse of what most people do.

Start by writing down the current process on one page. Where inquiries come from, who touches them, what the stages are, where things get stuck. This takes an hour and it is the document the whole decision rests on.

Then pick the single problem that costs the most. Usually it is lost inquiries. Configure it to solve that one thing and nothing else, and run it for a month.

Then add the second thing.

Then the third. A rollout that grows one capability at a time gets used, because at every point it is doing something people can feel. One configured completely before anyone touches it arrives as a wall of fields, and it gets abandoned.

• Write down the current process first. Before looking at any product.
• Name one problem to solve. The most expensive one.
• Use a trial period properly. With real inquiries rather than test ones, and with the whole team that will use the system, not only the person choosing it. Owners nearly always like a CRM for its reports; whether it takes root depends on the managers who enter every deal by hand.
• Import a small sample of data. To see how the import behaves.
• Give one person ownership. A tool nobody owns decays.

What gets connected first

Once the basic pipeline is running, the channels are connected one at a time.

The channel that brings the most inquiries goes first, then the next by volume. For most companies the candidates are the site form, the mailbox, the phone system and messaging apps, in whatever order their own figures put them.

For a shop the picture differs. There the orders already live in the shop platform, and what the CRM adds is everything around the order, such as questions before purchase, returns and repeat contact. The full picture of what a running shop costs to operate is in our article on the running costs of an online store.

Integrations of this kind fall under ordinary custom web development rather than being a separate discipline. What makes them fail is almost never the technical side but the absence of an agreed rule about which side holds the truth when the two disagree.

Mistakes that stop a CRM from taking root

The pattern of failure is consistent enough to list.

• Too many mandatory fields. Every one is friction on every record.
• No agreed rule about what goes in. Half the team uses it, half does not.
• The old spreadsheet still running. Two sources of truth means neither is trusted.
• Configured by somebody who left. Nobody knows why it works that way.
• Bought for reports the owner never reads. The staff notice this quickly.
• Rolled out to everyone at once. With no pilot on one team first.

The spreadsheet running in parallel is the most reliable predictor of failure. As long as there is a second place where the real information lives, the CRM is documentation rather than a working tool, and documentation is the first thing to be skipped under pressure.

When a CRM is not needed

There are situations where the answer is “not yet,” and saying so saves a year of halfhearted use.

A business with a handful of inquiries a month and one person handling them does not have a coordination problem. A business selling a single product over the counter with no follow-up does not have a pipeline. A business whose real problem is that too few people are asking has a demand problem, and organizing three inquiries better produces three inquiries.

There is also the case where the requirement has outgrown a CRM altogether. When the task goes beyond tracking customers to automating the company’s internal work as a whole, what is needed is an application of your own rather than a sales tool, and the boundary between the two is drawn in our article on when your business needs a web app.

Conclusions

A CRM is worth having when things are being lost between channels and people, and it is worth exactly as much as the discipline of using it.

The route that works is small and sequential. One problem, one month, then the next. The route that fails is buying the most capable product available, configuring everything in a week and expecting the team to adopt it because it is there.

If you are not sure which of the three routes fits your case, describe how inquiries reach you now and how many people touch them. We will say whether a ready-made product covers it, what would need connecting to your site, and whether the problem you have is actually a CRM problem at all. Sometimes it is not, and that is a cheaper answer than a rollout.