An owner tells me they bought a customer system eighteen months ago, paid for setup, ran training, and today two of their four salespeople use it. One updates records the night before the monthly meeting. One does not touch it at all, and he is the best seller in the company.
This is the normal outcome, not an unlucky one. The usual responses are more training, a policy, or a different product, and none of them work, because none of them address what is actually wrong.
The real reason adoption fails
Look at who pays and who benefits.
A salesperson spends fifteen minutes a day entering activity. In exchange, management gets a pipeline report, a forecast, and visibility into what the team is doing. The rep gets nothing they did not already have, since they knew what was in their own pipeline before they typed it in.
So the system, as most small companies configure it, is a reporting tool that runs on somebody else's unpaid labour. Reps understand this immediately, even when nobody says it. Then the response is compliance theatre: records updated in a rush before the monthly meeting, stages moved to whatever looks acceptable, notes that say "called, will follow up." The reports come out clean and describe nothing real.
Training does not change this arithmetic. Neither does a policy, because a policy is enforced by a manager who cannot tell the difference between a thin record and a fabricated one. The only fix is to change the trade so the person entering the data is also the person who benefits from it.
Make the system give something back
Four things a rep should get from the system that they cannot get from their own memory or inbox. Every one of these is configuration rather than new software.
Their follow-ups, planned for them. The main cost of selling without a system is forgetting. A rep with thirty live deals is holding thirty timelines in their head, and some fall out. If the system produces a daily list of exactly who to contact today and why, it is doing work the rep would otherwise do badly. This is the single strongest adoption lever I know of, and the reason the quote follow-up system and the customer system are really the same project.
Context before a call, without digging. When a rep opens a record they should see, in one screen, the last three interactions, what was quoted, what the client asked for, and anything the delivery team logged. Assembling that from email takes ten minutes. Reading it takes thirty seconds. That is a real return on the typing.
Documents they would otherwise build by hand. Generating a quote or a proposal from the record, prefilled, saves a rep an hour per deal. Once a rep learns that a complete record produces a document in two minutes, the record gets completed without any instruction from you.
Their own numbers, visible to them first. A rep should be able to see their pipeline, their conversion rate by stage, and how they compare to last quarter, before any manager discusses it. Good salespeople are competitive and want the scoreboard. A system that shows numbers only to management reads as surveillance.
The test to apply to every field and every requirement: what does the person typing this get out of it. If the honest answer is nothing, either build a return or delete the field.
Cut the required fields to the minimum
Most failed setups at small companies are over-built, and they were built with good intentions. Somebody asked what would be useful to know, everybody contributed, and the result is twenty-two fields on a contact record and eleven on a deal. Now logging a call takes five minutes instead of thirty seconds, and reps stop logging calls.
Cut hard. For most small B2B companies the genuinely required set is short: company, contact, deal value, stage, expected close date, next action, next action date. Everything else becomes optional.
Two field-level rules matter more than the count. Avoid free text where a short list will do, because free text cannot be reported on and it takes longer to type. And never require a field at a stage where the answer is not yet known, which is the most common design fault I see. Asking for a close date at first contact forces the rep to invent one, and an invented date pollutes every forecast built on it.
Run this test on your own setup: open a deal record and time yourself creating it honestly. Over ninety seconds and your reps are not doing it, whatever the reports say. The wider set of setup mistakes is covered in the post on small business onboarding mistakes.
The owner has to use it in public
At a 10 to 50 person company the owner sells, and what the owner does with the system decides everything.
If the owner keeps their own deals in a notebook and asks in the weekly meeting how things are going, the message is that the system is for other people. Reps read that accurately, and no policy survives it.
What works is visible use. In the weekly sales meeting, open the system and run the meeting from it. Ask about the deals showing on the screen. When somebody mentions a deal that is not there, add it during the meeting. When a rep says a stage is wrong, change it in front of everyone. Fifteen minutes a week of this teaches more than a training day.
Then stop asking for the same information in other channels. If a manager accepts a pipeline update over a coffee, the system has just been made optional. "Put it in the system and I will look before our call" is a sentence that has to be said several times before it becomes the norm.
The owner should also enter their own deals, including the messy ones. Reps notice whether the founder's pipeline is in there.
The salesperson who keeps everything in their head
Most small companies have one. Often the best producer, and often resistant in a way that feels personal.
Usually two things are happening at once. The first is habit. They built their book over years with a method that works for them, and the system asks them to spend time on something they do not need. The second is less comfortable: their knowledge is their security. A rep who is the only person who understands their accounts is harder to replace, and some of them know it.
Handle the first with time saved rather than argument. Have someone else enter their existing accounts for them so they are not asked to do historical data work. Set up their follow-up list and their document generation first, so their first experience of the system is receiving something.
The second requires the owner to be direct, and calmly. The business needs to be able to serve a customer when the person who owns that relationship is on holiday or leaves. That is a reasonable requirement of any employee and it is not an accusation. Put it in writing as an expectation of the role, with a date, and apply it to everybody equally.
If a top producer refuses outright, you have a judgment call about risk, and the right answer depends on how much revenue is concentrated in that one person's head. The concentration itself is the problem worth fixing, whether or not this particular rep ever complies.
When to accept partial adoption
Complete adoption is not the goal, and chasing it wastes a great deal of management attention on the last stretch.
Decide what you actually need the system to answer. For most small B2B companies it is four things: who is in our pipeline, what is it worth, what is the next action on each, and where do deals die. Every one of those is served by the short required set above.
Activity logging is where owners overreach. Knowing that a rep made eleven calls on Tuesday changes no decision at a company of this size, and requiring it costs you the goodwill you need for the fields that matter. Let call logging be optional, or let a tool capture it automatically, and spend your insistence on pipeline accuracy.
My working standard: every live deal in the system with a value, a stage, and a dated next action. That is enough to run a company, and it is achievable. Perfect notes on every interaction is not, and pursuing it tends to cost you the basics.
Automation and AI note-taking as the lever
This is the change that has moved adoption more than any policy in the last two years, and it works because it removes the typing rather than motivating it.
Meeting assistants that join a call, transcribe it, and produce a summary now write the note for the rep. Connected to the customer record, the summary and the action items land on the deal without anybody typing. The rep's job becomes reading and correcting, which takes a fraction of the time and which people actually do.
Email and calendar syncing does the same for the rest. Messages and meetings with a known contact attach themselves to the record, so the history builds without effort. Most current systems include this and many small companies have never switched it on.
Two cautions. Tell people, and get consent for recording, because Canadian privacy expectations around recorded conversations are real and a client who discovers a recording afterwards has a legitimate complaint. And do not let automatic summaries replace the rep's judgment: the transcript records what was said, while the useful note says what it meant and what happens next. Ask for one line of human judgment on top of the generated summary.
A broader view of where automation earns its place at small companies is in the automation guide.
The takeaway
Adoption is a design problem. The system as most small companies set it up takes time from reps and gives value to management, and no amount of training corrects an unfair trade.
Fix it in this order. Cut required fields until an honest deal record takes under ninety seconds. Turn on the daily follow-up list, the one-screen context view, and document generation, so the rep gets something back. Run your weekly meeting from the screen, and enter your own deals where everyone can see. Switch on email syncing and a meeting assistant so the notes write themselves.
Then settle for the four things you actually need and stop chasing the rest. In my view a company that has every live deal recorded with a value, a stage, and a dated next action has all the system it needs, and most of the ones spending money on more are still missing those four.