In every automation quote there is a line that reads «data audit and normalization» with no hours next to it. That line is your spreadsheet, and how much it costs is written by you: the tidier it arrives, the smaller it gets.
Yes, you can automate without a CRM. Most of the automations an SMB buys read from and write to a spreadsheet, not to a management system. What has to be prepared beforehand is four columns: an id that is never reused, the phone in a single format (+5491154238899), a status picked from a closed list of five words and a last_updated with date and time. They are added at the end of the spreadsheet in one afternoon, without migrating anything or changing tools, and they don't have to be redone later. Without those four, any project starts by cleaning your spreadsheet, and you end up paying for that cleanup in setup hours.
The problem isn't Excel: it's that your spreadsheet is written for a human
You open the spreadsheet, look at a row and in three seconds you know everything: "Marcela – 2-room in Palermo – said she'd get back to me on Thursday". That understanding isn't in the spreadsheet. It's in your head. The cell says "said she'd get back to me on Thursday" and doesn't say which Thursday, or whether Marcela is still alive as an opportunity or fell through a month ago.
A system doesn't infer. It needs every row to answer three questions without ambiguity: who this person is, uniquely; what exact point they are at; and since when they've been there. SMB spreadsheets almost always have the first one half-solved —the same customer entered three times with the phone written differently— and the other two simply don't exist.
The good news: fixing it isn't migrating to a CRM or changing tools. It's adding columns.
The four columns, with the exact names worth giving them
They go at the end of the spreadsheet, the order doesn't matter. What matters is that the header is in row 1 and is always spelled the same way.
| Column | What goes in it | Example |
|---|---|---|
id | A number that only goes up and is never reused, not even if you delete the row | 147 |
phone | Country code + number, all together, nothing else | +5491154238899 |
status | One word from a closed list of five. Never free text | waiting-reply |
last_updated | Date and time when that row was last touched | 2026-07-31 16:20 |
The id exists because rows move. You sort by date, delete two, insert one at the top, and today's row 34 isn't yesterday's row 34. Any automation that has to come back to the same row needs an identifier that doesn't depend on position. The rule for keeping it manageable is a single one: the next number is always the highest one you have ever used, plus one. Even if you deleted 146, the next one is 148.
The phone in a single format is the column that will save you the most money. "11 5423-8899", "1154238899", "+54 9 11 5423 8899" and "15 5423 8899" are the same person to you and four different people to any system. WhatsApp identifies the contact by the exact number. If the same person is written in two ways, you are going to send them two messages, and that is the mistake that gets a customer to block you fastest. The format is: + followed by the country code, no spaces, no dashes, no parentheses, no leading 0 and no 15. Argentina +5491154238899, Spain +34612345678, Italy +393331234567.
The status has to be a closed list of five values and never grow. These work: new, contacted, waiting-reply, won, lost. The distinction that makes it work: the status describes where the opportunity is, not what you did. "I called them" is an action and it has already happened; "waiting-reply" is a state and it is still true right now. If you feel you are missing a sixth value, that nuance goes in a note column, in free text, where it bothers nobody.
The last_updated is the one everybody skips and the one that makes everything else possible. Almost every useful follow-up automation has the same shape: "if this row has been in such-and-such status for more than X days, do something". Without that column, that rule can't be written, and there is no way to reconstruct it later by looking at the old spreadsheet. Date and time, and the golden rule: if you touched the row, you update it. A date column that isn't maintained is worse than not having one, because you are lying with precision.
Fill them in only on the open rows: the rest is history
The mistake that makes people give up is trying to backfill all 800 rows. There's no need. Most of them are closed history you are not going to touch again.
Twenty minutes, in this order:
- You insert the four columns at the end and number the
idfrom top to bottom. A drag does that. - Everything already closed:
statusset towonorlost, and inlast_updatedthe last date you know, even if it's approximate. Done, never touched again. - The rows that are still alive —the ones that at an SMB are usually a few dozen— one by one: phone into format, real status as of today, date of the last time there was actual contact.
From then on there is a single discipline to keep: you touched the row, you update the date. If in two weeks that column has gone stale on you, it isn't a spreadsheet problem, it's the first concrete sign that manual follow-up is no longer enough.
Sorting by that date builds today's call list
This works this very afternoon, without automating anything: filter status to waiting-reply and sort by last_updated from oldest to newest. What ends up at the very top is the contact nobody has touched for the longest, which is almost always the one you are about to lose without noticing.
Set the cutoff at 7 days and count how many rows are left on the other side. That number —yours, not an average off the internet— is the first real metric you will have of your sales process, and it comes out of two clicks.
Color is not data: three habits to drop
These three things make the spreadsheet unreadable for any system, and all three are habits, not mistakes.
Coloring cells to mark status. Yellow is "owes me", green is "already came in". That meaning lives in your head and nowhere else: color doesn't travel, it can't be filtered reliably and nobody but you reads it. If a color means something, that something goes in a column.
Merging cells. A merged cell breaks the row structure: there stops being one row per thing. It is the number one reason a spreadsheet has to be rebuilt from scratch.
Putting several tables on the same sheet. Headers in row 4 because there's a title above, total rows in the middle, two lists separated by three blank rows. One sheet, one table, headers in row 1, no empty rows in between.
And a fourth one that is about process, not format: if your spreadsheet lives on your computer's desktop or travels as an email attachment, you already have more than one version going around and none of them is the real one. Moving it to Google Sheets or Excel online is the only remotely technical thing on this whole list.
One clarification so as not to confuse two different things: the fact that a spreadsheet in the cloud is enough doesn't mean it works for everything. It is enough —more than enough— for something to read one row, write another and send a message: those are one-row-at-a-time operations, and the shape of the spreadsheet hardly matters. It stops being enough when what you want on top is a dashboard that charts the total every day: there the spreadsheet is the most expensive source, because every export is held up by a person and because a new column or a total at the bottom breaks what was already built without warning. If you are thinking about that, we do the math in how much a custom BI dashboard costs. Automating messages on top of your spreadsheet is cheap; charting it every day is not.
The spreadsheet doesn't break by size: it breaks when the daily list goes past an hour
The limit isn't the one usually quoted. The spreadsheet doesn't fall over because of row count: Sheets and Excel handle thousands without breaking a sweat, and out of your 800 rows the vast majority is closed history nobody is going to open again. The only thing that breaks is what you have to touch every day.
And that can be calculated. With the cutoff at 7 days, each open row falls back into the list once a week: today's list is, roughly, your open rows divided by seven. Put four minutes per follow-up actually done —open the conversation, write, go back to the spreadsheet and update the row— and the limit shows up on its own:
- 40 open rows → 6 a day → less than half an hour. The spreadsheet is more than enough and you need nothing else.
- 105 open rows → 15 a day → exactly one hour. That is the ceiling.
- 200 open rows → 29 a day → almost two hours. At that point you aren't doing follow-up: you are administering a spreadsheet.
When the daily list goes past an hour, it stopped being a list. That is the practical cutoff, far more useful than counting total rows: if touching what the spreadsheet flags for you every day takes more than an hour, one more column isn't what you are missing.
Before that ceiling there are two ways of breaking that don't depend on volume and are worth recognizing, because they arrive much earlier:
The first thing that falls isn't the row: it's the date. The row is always a hand-typed copy of something that happened somewhere else, and it gets typed afterwards. You write the phone number correctly because you need it today; last_updated gives you nothing today and only pays off three weeks from now, so it's the first one skipped on a day when you are in a rush. When that happens the 7-day filter doesn't break, which would be better: it keeps returning a list, a shorter one, with the people who got frozen out of it.
The spreadsheet doesn't come looking for you. The 7-day filter works if you open it. On a difficult day you don't open it, and the 7-day rows turn into 20-day rows without anything making a sound.
And there is a third limit that isn't about time but about hands: two people writing on the same spreadsheet don't warn each other. Sheets doesn't merge edits on the same cell —the last one wins— and in Excel online the row one person has just closed gets reopened by the other without noticing. That is the real trigger for a CRM, long before the number of rows.
Automating isn't replacing the spreadsheet: it's having someone else write the row
What changes when you automate isn't where the data lives. The spreadsheet can stay exactly the same, with the same four columns. What changes is who writes.
The row is written at the exact moment the conversation exists, not when someone remembers to copy it over: the phone comes in already as +549… because it comes from the number the person wrote to you from, and the status starts at new. There is no typing in between, which is where the two hardest columns get lost. The last_updated overwrites itself on every touch —the column no person sustains three weeks in a row— and the 7-day list stops being something you sort when you remember: it arrives ready.
That is where the four columns stop being tidiness and become the contract: they are exactly the four pieces of data any automation needs in order to operate on your spreadsheet without guessing.
That is why it is worth sustaining the four columns by hand for a couple of weeks before automating anything: they are also a test. If after two weeks five values aren't enough for your status, your process has more steps than you thought, and that gets defined before automating, not after.
If you did those two weeks and your status grew to eight values, send us the list at info@striqtech.com. That list is your real process written down for the first time, and what usually shows up on reading it is that two or three of the eight are the same step with different names depending on who filled in the row. Merging them is free and gives you back a five-value spreadsheet without losing anything.
If your spreadsheet has these four columns, any quote will come back cheaper
Not out of the provider's goodwill: because the setup hours that go into normalizing phone numbers, deduplicating contacts and inventing a history that doesn't exist disappear from the scope.
There is a cheap way to check it before signing anything. When you ask for a quote, don't send a document explaining your process: send the spreadsheet, with twenty real rows, the phone numbers as you have them and the statuses as you write them. If the proposal that comes back doesn't name any of the four columns and doesn't ask you about the rows where the phone is in three different formats, they haven't opened the file yet, and that number is going to be corrected upwards in the second meeting.
And if what you are after is the opposite answer —confirming that automating isn't worth it for you yet— it comes out of the same spreadsheet and without calling anyone. Next Monday, time how long it takes you to build the list sorted by last_updated, and count how many rows were left with an old date because nobody touched them. Less than an hour and fewer than five frozen rows means the spreadsheet will hold you for another full six months, and that any proposal you receive this week is going to be expensive compared with that.
Frequently asked questions
Can I automate WhatsApp if my customers live in a spreadsheet and not in a CRM?
Yes. A spreadsheet in Google Sheets or Excel online works perfectly well as the base for a first messaging and follow-up automation: rows are read and written just like in a database. What makes it unusable is not the format, it's loose writing: phone numbers in five different formats, statuses in free prose and no mark of when each row was touched. Fix those three things and the spreadsheet stops being an obstacle.
Google Sheets or Excel: which one is better if I want to automate later on?
Either one, as long as it lives in the cloud and not on your computer's desktop. A local .xlsx file, or one going around as an email attachment, is a dead end: nothing external can read it unless you upload it by hand, and it multiplies into versions. For reading and writing rows and triggering messages, Google Sheets and Excel online work the same and are more than enough. Using that same spreadsheet as the source for a BI dashboard is a different story: there it is still the most expensive source, because someone has to keep the export alive and because the spreadsheet changes shape without warning whatever is built on top of it. Moving the spreadsheet to the cloud is the only remotely technical part of this whole preparation and it takes two minutes.
How should I write phone numbers so they work for WhatsApp later?
All together, with the country code in front and nothing else: no spaces, no dashes, no parentheses, no leading 0 and no 15. An Argentine mobile ends up as +5491154238899, a Spanish one +34612345678, an Italian one +393331234567. WhatsApp identifies the person by that exact number: if the same person appears written in two ways, to the system they are two different people and you will duplicate messages.
Do I have to clean up my whole old spreadsheet before automating?
No, and doing it is the fastest way to abandon the attempt. If you have 800 rows, most of them are closed history you are never going to touch again: those get marked won or lost with the last date you know and are left alone. The real cleanup is only on the open rows, which at an SMB are usually a few dozen. That is done in one twenty-minute session.
When is it worth moving from the spreadsheet to a real CRM?
When more than one person is selling with their own book of business and you need to see who touched what and when, without asking. With a single salesperson, a CRM is usually a spreadsheet with more clicks and a monthly fee. The trigger is not the number of rows either: the spreadsheet holds thousands. It is the number of hands writing on it at the same time.
Implement this in your business in 72 hours
Let's talk for 15 minutes. No cost, no commitment. I'll audit one process and show you the projected ROI.
Let's talk on WhatsApp