A spreadsheet never breaks with an error message. It goes quietly, and the first symptom is that you stop trusting it. You open the sheet, find a customer, look at the phone number, then call the number saved in your own phone instead, because you're not certain which one is current. That's the day it stopped being your customer database and became a document about your customers.
Everyone should start with a sheet. Fifty rows, six columns, name and number and what they bought. Costs nothing. Takes four minutes. Beats the shoebox of business cards it replaced, and nobody is wrong to start there. What gets people is the assumption that the sheet will keep up, and that the day it stops keeping up will announce itself.
What you actually want the thing to do
A customer database has a short job description. Hold one record per human being, permanently, and attach everything that ever happened to that person to that one record. Every quote, every job, every invoice, every missed call. If somebody has hired you four times over six years, that's one person with four jobs hanging off him. Four rows with his name spelled three different ways is a different animal.
After that, five more things:
- Fill itself in from wherever customers actually arrive, so the website form, the phone and the checkout all write to the same place and nobody retypes anything
- Answer questions you didn't plan for, like who hasn't booked since March, or which town the profitable jobs come from
- Let two people work in it at once without one of them flattening the other's work
- Know the difference between a date, a phone number and a note, instead of treating all three as loose text
- Belong to you completely, exportable in full, on a day when you're irritated with whoever hosts it
A spreadsheet does one of those well, and it's the last one.
Duplicates are the whole problem
Picture a customer. Call him Mike. He calls in March and you type "Mike Reilly". In August his wife books the same job and you type "M and J Reilly". In January he texts from a work phone you don't recognize, so you add a third row. Mike is now three customers. Your repeat rate looks worse than it is. Your seasonal message goes to him three times. And the note about the dog that bites is sitting on the row nobody opens.
A real database makes that hard to do. The phone number is the key, so the second Mike gets matched to the first one and the history stacks up in a single place. That one behavior, refusing to create a person who already exists, is worth more to a small business than most of the features anyone will try to sell you.
Nobody ever notices the bad sort
Someone highlights column C. Sorts it alphabetically. Now every name is attached to the wrong phone number, with no warning and no undo three days later. Meanwhile there's a copy on a laptop, a version that got emailed to the bookkeeper in April, and a file called customers_final_v2. You can't say which one is true, so you rebuild from memory. Which means you keep last week's callers and lose everyone who hasn't called in two years. Those are the ones with the most money left in them.
A database nobody types into
Data entry is a tax, and it always gets paid by whoever has the least time. That's why the shoebox lost. It's why the sheet loses too. The record should be created by the event itself. Someone submits the form on your site at 11pm and a record appears with the address, the job type and where they came from. Someone calls while you're lying under a sink, and the record comes out of the call.
That second one is where most of the leakage happens. A 411 Locals study found that 62 percent of calls to small businesses go unanswered, and every one of those callers was trying to put themselves into your database. Name, number, problem, all ready to say out loud. A voicemail box catches none of it, and the Numa Small Business Phone Report found that 85 percent of callers who reach voicemail never call back. So the record never gets created. And it never will.
The questions are the point
Storage is cheap and boring. What you're actually buying is the ability to ask something on a Sunday night and get an answer before you lose interest in the question. Every customer within ten miles who bought the maintenance plan and hasn't been seen in eleven months. Every job over 800 dollars that came from the website instead of a referral. Everyone who still owes you money and hasn't been chased.
In a spreadsheet, each of those is an afternoon of filtering, copying into a new tab and squinting at the result. So you don't ask. And a business that never asks ends up buying new customers at full price while the old ones drift off quietly, still available, waiting to be called by somebody else.
When to move
There's no signal from the sky. Move when a second person needs to touch it. Move when you catch yourself keeping a second list somewhere else. Move when you want the website or the phone to write into it. Move when someone owes you enough money that you'd rather the system remembered it than you. Any one of those on its own is enough. The migration is usually a morning's work, since exporting a sheet to CSV takes one click and CSV is what the new system wants to read.
What you move to matters less than people assume, as long as it holds real records, real logins, and a way for other things to write into it. Look at a few, and check each vendor's current pricing yourself, because pricing moves and anything you read about it secondhand is already out of date. Rocketship builds that part from a plain English description of the business: customer database, customer logins, Stripe payments through your own Stripe account, an admin dashboard, live on your domain in minutes. Free to start, 12 dollars a month at the low end. The same system answers the phone, so a call at 7pm turns into a record with a name on it before you've finished dinner.
Try this on whatever you're using now. Pick a customer at random and ask the software what happened the last time they hired you. If the answer lives in somebody's head, the sheet stopped working a while ago.
