Your enquiries live in chats. Do you need a CRM yet, or will a spreadsheet do?

A customer messages you on Instagram. You reply from your phone between two meetings. Then they send measurements on Viber, ask about the price on Telegram, and request an invoice by email.

You don’t have an order yet. But you do have a little digital treasure hunt.

That evening, you’re sure you’ve replied to everyone. In the morning, you discover you promised to call one person back, recalculate the price for another, and apparently left a third to your colleague. Your colleague is sure you took that one. Meanwhile, the customer has chosen someone else.

Somewhere around this point, the business utters the sacred words: “We need a CRM.”

Perhaps you do. But before choosing a system with beautiful charts, work out what it actually needs to fix. Moving confusion from messengers into more expensive software counts as digital transformation too. Just a rather sad version of it.

Let’s work out when a spreadsheet still does the job, when it starts getting in the way, and how to test a CRM against your work rather than a salesperson’s presentation.

The product examples were checked on 6 October 2026. This is not a CRM ranking or a recommendation of a particular subscription plan. The process advice consists of editorial recommendations; the workshop example is hypothetical.

Messaging isn’t a problem in itself. A customer may find it convenient to send a photo in a messenger, talk on the phone, and confirm the details by email. Banning that for the sake of your internal organisation is an odd way to begin a customer relationship.

The problem starts when the conversation is the only place you can find out what’s happening with an order.

To answer a simple “Have we sent the proposal yet?”, you have to open three apps, find the right person, scroll through voice messages, and ask an employee whether they agreed anything over the phone. If that employee is on holiday, your business suddenly discovers archaeology.

Separate the conversation from the record of what you’ve agreed. You can talk in a chat. But the person responsible, the current status, and the next step need to be in one designated place.

You don’t need to copy every “thanks” and emoji. You need to keep whatever affects what happens next:

• who contacted you and how to reach them;
• what they need;
• what you’ve already agreed;
• who is responsible for the enquiry;
• what needs to happen next, and when;
• how the enquiry was resolved.

Yes, this sounds less impressive than an “omnichannel customer experience management platform”. But it does tell you what to do at ten on Tuesday morning.

We’ve already covered the basic journey from enquiry to work and payment in “Order in leads, work and payments”. Here, we’ll go a step further: choosing where to keep that process organised.

Imagine a hypothetical workshop. Someone asks about repairing a table, checks the delivery arrangements, and a month later orders some shelves as well.

That’s one customer. But different orders.

If you create a new “customer” after every message, your database will soon become a club for lookalikes. If you keep all their orders in one row, it will be difficult to tell which invoice has been paid and which delivery date you’re discussing.

It helps to distinguish three things:

A contact is the person, or company representative, you talk to.

An enquiry or deal is a separate need you’re currently discussing, from the initial request through to agreement or rejection.

An order in progress is agreed work with its own terms, deadlines, and payment.

For simple record-keeping, you can combine some of these. What matters is that everyone on the team understands what one record represents. In an initial spreadsheet, that will often be an individual enquiry or order, with contact details repeated. That’s a practical simplification you need to choose deliberately.

In a CRM, these records may be separate and linked. For example, HubSpot’s documentation describes associations between contacts, companies, and deals. This is an example of how one particular system works; other products may use different names and offer different features.

The question before implementation is simple: will I be able to see all of one customer’s orders without mixing them up?

A spreadsheet is a perfectly reasonable working tool. It doesn’t need to apologise for having neither a sales department nor a stand at a conference.

It can suit you if one person or a small team handles enquiries, the stages are clear, and the records are updated regularly. You open the file and can see what needs doing today without launching an investigation.

Start with these fields:

Enquiry number. A simple unique number, so you don’t have to say “that Serhii who asked about doors, but not the one from last week”.

Date and source. When they contacted you and where they came from: a website form, a recommendation, advertising, or a particular messenger. If you don’t know the source, record that.

Contact and need. Their name, the contact method you need, and a short description of the task. Not their entire life story, just enough context to work with.

Person responsible. One designated person who owns the next step. Several people can help, but someone specific needs to be responsible for moving the enquiry forward.

Status. For example: new enquiry, clarifying the task, proposal sent, agreed, declined. This is an example, not a universal workflow for every business.

Next action and date. “Send two configuration options on Wednesday”, rather than “in progress”. The latter doesn’t tell anyone what to do next.

Agreed amount and payment. If you’re already discussing a specific order. Keep the quoted amount, the agreed price, and the payment actually received separate, so expected money doesn’t masquerade as money you already have.

Outcome or reason for stopping. Agreed, declined, decision postponed, unable to make contact. Record the reason as given by the customer, or mark it as an assumption.

Link to the details. The conversation, proposal file, or project brief, with access for the people who need those materials.

Don’t add forty mandatory fields “for the future”. If creating a record takes more effort than the conversation itself, the team will find a workaround. Most likely, the good old chat.

Agree with your team when to update the records: after a conversation, after an agreement, before handing something to a colleague. The file won’t work out what happened on its own. Even if the cells are beautifully coloured.

The point at which you need a CRM isn’t a magical number of customers. Five complex B2B deals can require more coordination than dozens of straightforward repeat orders.

Look for recurring difficulties.

Enquiries keep moving between people. Every handover needs an explanation: what you’ve already done, what you’ve promised, who needs to act. Details get lost, and the customer tells the same story several times.

Next steps depend on personal memory. The dates are in the spreadsheet, but people don’t check them. You need assigned tasks and reminders that fit into the working day.

You collect enquiries from different channels by hand. Every day, someone copies enquiries from forms, emails, or other sources. It takes time, and missed entries are hard to spot. Here, you need to check the integration with your particular channel, rather than a general claim that the system “supports messengers”.

The customer’s history is scattered. Repeat orders, several contacts at one company, different proposals and replies no longer fit comfortably in a flat list.

You need different access permissions. The team needs to see its own enquiries, the manager needs an overview, and an external contractor needs only the relevant materials. Not every spreadsheet makes that division convenient.

Preparing a report has become a project in its own right. Working out where deals stall is harder than fulfilling some of the orders. First you check the data, then you fix the status names, then you try to remember why “agreed” didn’t actually mean agreed.

These signs don’t oblige you to buy a system immediately. They give you requirements for one. If the problem is handing an enquiry between two salespeople, that is the handover you need to test during the demo. The smoothly animated chart can wait.

It won’t decide what makes a good enquiry if you haven’t agreed that yourselves.

It won’t create a realistic delivery deadline if the team doesn’t know its workload.

It won’t turn “call sometime” into a specific action if you don’t have a rule for that.

It won’t persuade employees to keep records if the manager continues to approve important changes in private messages and records them nowhere else.

A hypothetical example: a salesperson marks a deal as won because the customer wrote “OK”. Production takes that as permission to begin. The customer meant “OK, I’ll think about it”.

The software might notify everyone involved very quickly. You’ll have an automated misunderstanding with an excellent event log.

So define the condition for moving into every important status. For example: “Agreed” means the specific scope, price, and conditions for starting work have been confirmed. If you require an advance payment, record the payment status separately or include it in your clearly defined conditions for starting.

You don’t need a hundred-page rulebook. You need two people to give the same answer to this question: what needs to happen before we move a record here?

Before uploading customer contacts, decide who administers the system, who can add users, and how to get your data out if you choose to move to another tool.

Access to your working records needs to be part of employee onboarding and departure. A shared password that “everyone has somewhere” doesn’t help much when you need to understand who changed what and who still needs access.

If you start with Google Sheets, give specific people access to the file and assign suitable roles. Google explains the options for viewers, commenters, and editors. Also check access to the folder containing the file: permissions may be inherited from it.

And don’t confuse protecting cells with restricting access to the data. Google explicitly explains that protecting a sheet or range is not a security measure: a protected spreadsheet can be copied and exported. It’s useful protection against accidental edits, not a way to hide your customer database from people you’ve already given access to it.

When moving to a CRM, check the rules for matching records first. Otherwise, an import may create duplicates or update the wrong record.

For example, in HubSpot, email is used to match contacts, while imports can also use Record IDs or other unique values. The specific behaviour depends on the object and how it is added. This isn’t a rule for all CRMs, or a guarantee that any integration will automatically remove duplicates.

A practical approach: keep the original file, agree the field mapping, try an import with a small sample, and check the result. Establish where you’ll test and how you’ll remove the test records before you begin.

Test the export separately. HubSpot’s export documentation describes exporting record properties and associations. But don’t assume that any CSV is a complete copy of everything: check whether it contains the fields, history, notes, and file links you need. Some data may require another method of retrieval.

This follows the same logic we discussed in “Your contractor disappeared. What’s left of your website?”: you need to check access and your ability to keep working in advance.

Ask to see the system working with your scenarios. You can use fictional contacts and hypothetical orders for the demonstration instead of handing over your entire customer database.

Make it something closer to real life than the perfect enquiry in the presentation:

1. A new enquiry. Someone fills in a form. Where does the record appear, what data is saved, and who sees it? A delivered message doesn’t yet mean someone is responsible for acting on it.
2. Repeat contact. The same person writes again. How do you find the previous history? What happens if they use a different email address or phone number?
3. A handover to a colleague. The person responsible is off sick. Who takes the enquiry, and can they see what was agreed without searching that person’s private phone?
4. A change of terms. The customer chooses a different option. Where is the current proposal recorded, and how do you avoid starting work based on the old one?
5. The next step. You’ve agreed to return to the conversation on Friday. Who gets a reminder, and where? What do you do if the deadline is missed?
6. An enquiry fails to arrive. A form or integration hasn’t passed the enquiry through. How does the team notice the problem, and where does it check the original source? Not every system will provide the controls you need without additional configuration.
7. Completion and reporting. The deal is won or lost. Can you find the reason, the person responsible, and the confirmed outcome?
8. Leaving the system. You need to export the data. What do you actually get, and what is missing from that file?

Keep a record of the results: what works immediately, what needs configuration, what isn’t supported, and what costs extra. Check the limits of your particular plan and integration method.

If enquiries come from advertising, also check the journey from the source to the enquiry received. We discuss these gaps in “Ads are running. Where are the enquiries? What to check before increasing the budget”. A CRM can help you manage an enquiry you’ve received, but having one doesn’t prove your form and advertising are set up correctly.

You don’t have to move every contact, old conversation, invoice, stock record, and the accountant’s sacred spreadsheet at the same time. The sacred spreadsheet often has a belief system of its own.

Choose one clear flow. For example, new enquiries about a particular service. Decide from which point you’ll manage them in your chosen tool, who is responsible, and exactly what you’re testing.

Don’t maintain two equally authoritative lists. If the spreadsheet and CRM contain different “current” data, the team will spend its energy reconciling them. During a trial, you can retain the old records as a cross-check, but clearly define which source informs decisions and who compares the results.

To assess the change, look beyond the number of records created. Ask simple questions:

• Does every new enquiry have someone responsible for it?
• Can you quickly find the current agreement?
• Can you see overdue next steps?
• Can a colleague continue the conversation without a spoken recap?
• Is there less manual copying or searching?
• Is it clear what happened to the enquiries you received?

If the team spends more time filling things in without getting the answers it needs, review the fields, statuses, and daily workflow. It’s too early to buy the next module.

Ready-to-use wording for a team discussion: a template, not a customer quotation:

Let’s agree where we keep new enquiries. For each one, we record the person responsible, the current agreement, the next action, and its date. We update the record before handing it to someone else. If fields are awkward or something needs to be entered twice, we’ll collect specific examples and change the process. We’ll establish who checks records with no assigned person and overdue steps.

This is less ceremonial than announcing “we’re a digital business now”. But it helps keep the customer from getting lost between your very digital employees.

If you’d like to build a process that fits your business, write to GrandMa. We’ll start with how an enquiry moves through your business today and where the next step disappears. Sometimes the answer will be a simple spreadsheet. Sometimes it will be a CRM and the integrations you need. The choice should follow from the work that needs doing.