Most client systems start life as a spreadsheet. Someone makes a sheet with columns for name, phone, last visit and notes. It worked. Then a tab appears for follow-ups, another for payments, a colour code for "do not call", and a copy on someone's laptop that differs from the shared one. That is not a failure. It is how a business finds out what its system needs to do.
The question is not whether spreadsheets are bad. It is whether yours has quietly become the thing slowing the team down, and if so, how to move off it without losing records, history or the trust of the people who use it every day. This post covers both.
Signs the spreadsheet has become the problem
A spreadsheet's flexibility is exactly why it fails as a shared system once several people depend on it. Signs worth taking seriously:
- Two versions of the truth. There is the shared file and the copy someone downloaded, or the sheet and the WhatsApp group where updates actually happen. Nobody is sure which one is current.
- Overwrites and lost edits. Two people edit the same row, or someone sorts one column without the others, and a client's phone number now belongs to someone else. You only notice weeks later.
- No history. You can see what a cell says now, not who changed it, when, or what it said before. When a client disputes a payment or a package balance, there is no trail.
- Everyone sees everything. A spreadsheet has no real roles. The person who only needs today's appointments can also see revenue, client notes and the column you would rather they did not edit.
- Reminders depend on memory. Follow-ups, renewals and callbacks happen only when someone remembers to filter the sheet. On a busy week, they do not.
- The sheet has a single owner. One person understands the formulas, the colours and the hidden tabs. When they are on leave, the system is effectively down.
One or two of these is manageable. When several are true, the cost is already being paid in staff time and mistakes rather than an invoice.
Off-the-shelf CRM or custom?
First check whether a standard product already fits. For a typical sales pipeline (leads, deals, stages, follow-up emails) a mature CRM product is usually the sensible choice: it works quickly and someone else maintains it.
A custom CRM starts to make sense when one or more of these is true:
- Your workflow will not bend to the product. Your day is built around jobs, visits, packages, treatments, sites or contracts, not sales deals, and forcing it into a pipeline means fighting the tool.
- You need Arabic and English done properly. Right-to-left layouts, mixed-language names and bilingual messages are often an afterthought in generic tools. I covered what doing it properly involves in building bilingual Arabic and English apps.
- It has to connect to something you own. A booking form on your website, a mobile app your customers use, an accounting export your accountant expects in a specific format.
- You want the data in your hands. Not locked behind a per-seat plan, an export limit or a vendor that changes pricing.
If none of these apply, use the standard product and spend the budget elsewhere. If they do, the custom CRM development page explains how I scope and build one. For a concrete example of what the features look like in one industry, see what a CRM for salons, spas and clinics should do.
Your spreadsheet is the best requirements document you have
A sheet used daily for years is a precise record of what the business actually tracks, which is more useful than a feature list written from scratch.
When I review one, I look at:
- The columns. Each column is a field the team decided was worth recording. Columns that are always empty are candidates to drop. Columns full of free text that always say one of five things are really a dropdown.
- The tabs. Separate tabs usually mean separate things: clients, visits, payments, staff. Those become the main records in the new system and the links between them.
- The colours and comments. Colour coding is almost always a status nobody formalised: paid, overdue, VIP, do not contact. Each one becomes a proper field that can be filtered and reported on.
- The workarounds. A column called "notes 2", a row of totals someone pasted in manually, a date stored as text. These show where the sheet stopped fitting, and they are often the most important features to get right.
- Who edits what. If only the manager touches the payments tab and only reception touches appointments, that is the start of your roles. How to turn that into a sensible permission model is covered in roles and permissions in a business app.
From that review comes a short scope: the records, the fields, the statuses, the roles and the handful of screens the team will use every day. That scope is what a fixed quote is based on.
Cleaning the data before the import
A spreadsheet tolerates anything; a database with proper fields does not. Moving the data is mostly a cleaning job, better done deliberately than discovered on launch day.
The usual issues:
- Duplicates. The same client entered twice with a slightly different spelling, or once with a mobile number and once with a landline. Decide the matching rule (usually phone number, sometimes email) and merge before importing.
- Phone numbers in many formats. With and without country code, with spaces, with a leading zero, two numbers in one cell. Normalise them into one format so search, deduplication and any messaging integration work.
- Dates stored as text. "Last week", "12/3" and "March" are not dates. Some will be recoverable, some will need a decision to leave them empty.
- Mixed languages in one column. Names written in Arabic for some clients and in Latin letters for others. That is fine if the system expects it, but search has to handle both, and you may want both versions stored.
- Statuses in colours. Every colour has to be mapped to an explicit value before import, or that information is lost.
I usually write the import as a repeatable script rather than a one-off copy and paste. That way it can be run against a copy of the sheet, checked, fixed and run again until the result matches. The final run happens at cutover, on the latest version of the data. Rows that cannot be imported cleanly go into a separate list for someone on the team to review, rather than being silently dropped.
Agree beforehand what history is worth bringing across. Old visits that are rarely looked at can be imported in a simpler form or kept as an archived export.
Planning the cutover
The riskiest moment is the switch itself. A few rules make it calm:
- Pick a date and stick to it. Running the sheet and the new system in parallel for a long time sounds safe, but it creates exactly the "two versions of the truth" problem you are trying to fix. A short overlap to check the import is fine. After the cutover date, the sheet becomes read-only.
- Do the final import close to go-live. Freeze edits to the sheet, run the last import, check counts and a sample of records, then open the new system.
- Keep the old file. Archive a copy of the spreadsheet exactly as it was on the cutover date. If a question comes up about an old record, it can be answered.
- Launch with the people who do the work. A short session with each role on their own screens, using their own real records, is worth more than a manual. Staff trust a system faster when they see their clients in it.
- Expect a first few weeks of small fixes. Real use always finds edge cases a demo did not: a field that needs one more option, a filter reception wants, a report the manager used to build by hand. Plan time for them.
This is the same principle as scoping any first version of an app: launch the core the team uses every day, then add the rest once that core is actually in use.
What the new system should do that the sheet could not
The point of switching is not a nicer-looking grid. It is to get the things a spreadsheet cannot do reliably:
- One record per client, with their visits, payments, notes and history linked to it, instead of spread across tabs.
- An activity history, so you can see who changed a record and when.
- Roles, so each person sees and edits what their job needs.
- Reminders and follow-ups generated by the system from dates and statuses, not by someone remembering to filter.
- Simple reports that answer the questions you ask every month, without rebuilding them each time.
- A clean export, so your accountant or anyone else can still get the data into a spreadsheet when they need it. Spreadsheets remain useful for analysis. They just stop being the system of record.
- Backups, taken automatically and tested, which a shared file on someone's account rarely has.
One advantage of a spreadsheet is that the data is yours. Keep it that way: on a custom build, the code, database and hosting accounts should be in your name, and you should be able to export your records at any time.
What it looks like in practice
The public example of a custom CRM in my work is the one for Enchanté by Remy Daher, designed and developed in Lebanon in 2025. For a larger operational system that took over work which would otherwise sit in calls and sheets, the NeonTask case study shows a field-service platform with work orders, dispatch, receivables and reports, alongside a technician app. You can browse the rest on the work page.
Getting started
If your team runs on a spreadsheet that has outgrown itself, the most useful first step is simple: send a copy with the personal data removed or replaced with sample rows, a short note on who uses it and what they do with it each day, and what you wish it did. That is enough to tell whether a standard product would serve you better or a custom CRM is worth building, and to scope the first version if it is.
Email hello@eliechaaban.com or use the contact section, and we can go through it on a call.