When your list needs a CRM.

Of the 642 businesses I could read this September, the leading website platforms were Squarespace (125), WordPress (112), Wix (94), Shopify (41), and GoDaddy Website Builder and Weebly (16 each) (byImprint intake census, 8 September 2026). Purpose-built booking software was far less common: Jane led with 62 sites, then Square Appointments (13), Yelp Reservations (12) and Calendly (10); every other named booking vendor I found had 5 sites or fewer.

The visible website evidence names a small number of quoting and booking tools, including Google Forms (9), Jotform (6), HubSpot Forms (6), Jobber (5) and Housecall Pro (3). It cannot show whether a business uses a private CRM, inbox, spreadsheet or another internal system.

That context is not a local default to follow. Compare a spreadsheet and a CRM against your own workload, records, handoffs and access needs.

Payment processing showed a similar pattern to booking and quoting: Stripe was the clear leader at 27 sites, then Square Payments (9), with PayPal, Clover Payments and Moneris each in single figures. Chat and messaging tools were rarer again, a WhatsApp link on 9 sites, Zendesk Chat on 5, and every other named tool below that (byImprint intake census, 8 September 2026).

Review-display widgets, Trustindex on 9 sites and Elfsight on 6, and email marketing tools, Klaviyo on 10 sites, Mailchimp on 3, Constant Contact on 2, were less common still. None of this is a recommendation to run any of these specific products; it is evidence of what a typical Squamish business actually has running today, so you can judge whether your own setup is unusually simple, unusually complex, or about average for the town.

The gap between the 642 sites read and the smaller visible counts against named vendors shows only what those public websites expose. It does not establish what each business uses internally or which system would suit it.

Ask how the team actually uses the list. Do several people update it at once? Is the conversation history elsewhere, in an inbox or a notebook? Can someone see the next action without asking the owner directly? Are permissions or accidental edits already creating problems that get quietly fixed and never discussed?

A small, complicated process can outgrow a spreadsheet before a much larger, straightforward list does. The number of records is only one part of the decision, and often the less important part; twenty customers with a messy, branching process can strain a spreadsheet harder than two thousand customers with one simple, repeatable step.

If the spreadsheet already works well for the team, that is a real answer, not an interim one waiting to be replaced. Do not treat a working spreadsheet as embarrassing just because a CRM exists; treat it as evidence the current scope of work does not yet need one.

Use the same small set of real tasks to assess both options. Do not score a product highly for a feature nobody on your team has agreed to actually use.

Walk through the five rows below with the actual product in front of you, not the sales page. A demo shows the feature working in ideal conditions; you need to know how it behaves with your messiest real record, not your tidiest hypothetical one.

The same September read recorded public enquiry, quote and order paths that did not expose an online system. Those paths may lead to a form, a direct phone or email link, or no visible route. This is a visible-path observation, not a measure of manual workload, demand, or unavailable service.

That is not automatically a problem. A spreadsheet or a well-run inbox can carry a business a long way. The decision point is whether your own team can answer a customer question, find the current record and hand work over reliably.

Watch for the specific moment this shifts: a second person joins the team and needs the same customer history the founder has been carrying in their head, or the founder is away and the business cannot answer a routine question until they are back. That moment, not a target row count, is the actual signal this guide is asking you to notice.

Illustrative test: an enquiry arrives, a colleague takes over, the customer changes a detail, and a quote is sent. Can the next person find the current state and the full history without opening five different places, an inbox, a notebook, a spreadsheet tab and a text thread, to piece it together from scratch?

Test a duplicate contact too. Decide how the business distinguishes two people with the same name and avoids splitting one conversation across several records, because that is where a spreadsheet and an under-configured CRM fail in exactly the same way, and where a demo rarely shows the failure to you.

Run the test with the person who will actually use the system day to day, not only with the owner. A tool that the owner finds intuitive but the team finds awkward will quietly fall back to the old habits within a few weeks of going live.

Migration involves checking fields, removing genuine duplicates, preserving useful history, and deciding what should remain an archive rather than an active record. There may be subscriptions, training, integrations, and a period when the team needs direct help getting comfortable with a new place to look.

Try a small sample before moving the full set. Keep a recoverable source copy and compare the migrated records against it line by line. An imported row count alone does not prove the information moved over correctly; a customer’s history can survive the move with the wrong dates attached and still look complete at a glance.

Budget real time for this, not just money. A migration that is rushed to hit a launch date tends to produce exactly the kind of unreliable record this guide is trying to help you avoid, which defeats the purpose of moving in the first place.

Before pricing a CRM, list what it would actually replace: the shared-inbox ownership rule, the booking or quote paths above, and whatever spreadsheet or notes app currently holds the customer history. A CRM that adds a fourth place to check, alongside the inbox, the booking tool and the spreadsheet, can make ownership harder rather than easier.

If the honest answer is that only one of those needs replacing, a smaller fix, like setting one owner for the shared inbox, may solve the actual problem for less disruption and no new subscription to maintain.

Stay with the spreadsheet if it meets the actual requirements and has a clear owner. Choose a CRM when the additional structure makes daily work more dependable, enough to justify the cost and the upkeep it needs to stay useful.

Agree what the old tool becomes after the move. Two active lists with different owners can recreate the same confusion in a more expensive form than the one you started with, and it is worth writing down explicitly that the spreadsheet is retired, not merely quiet.

Revisit the decision on a schedule, once or twice a year, rather than only when something breaks. A tool that was right for a five-person season can become wrong for a fifteen-person one without anyone deciding that on purpose.

Before signing anything, check whether the CRM already connects to whatever you use for payments or booking; most of the specialist tools that showed up often enough in the census to name, Stripe for payments, Jane for booking, Klaviyo for email, have existing integrations to common platforms, and a CRM that cannot see that activity without manual re-entry has only moved the duplicate-entry work into a more expensive piece of software.

A focused discovery session looks at one workflow, including a spreadsheet-versus-CRM question, and ends with a written recommendation, CA$750, credited toward a related project if you go ahead within 30 days (byImprint pricing, current terms). It is cheaper than migrating twice.

Bring the actual spreadsheet or the actual shortlist of products to that conversation. A recommendation grounded in your real data and your real team is worth more than one based on a general description of the problem.