Test enquiry ownership, repeated contact records, shared editing and access needs before deciding whether to improve your spreadsheet or move to another system.
Direct answer: Keep the spreadsheet if every enquiry has a clear owner, a reliable next action and an appropriate shared access arrangement, and the team can maintain its contact history without repeated repair. Restructure it before replacing it when the main problem is duplicated fields or inconsistent entries. Move to a system with verified record relationships or access controls when those requirements cannot be met safely and maintainably in the existing arrangement.
Five users is not a meaningful migration threshold. A small team with straightforward enquiries may manage comfortably in a sheet, while the same number of people handling restricted cases and many connected contacts may need a different system.
My default is to retain a working spreadsheet rather than buy a customer-management product merely because the team has grown. The recommendation changes when the information structure or access requirements have outgrown what the team can reliably maintain, even if the total number of rows looks modest.
Test the record, not the reputation of the tool
Use The enquiry-record stress check, an editorial method that follows one enquiry through assignment, follow-up, handover and closure. It asks whether the information survives normal work, not whether a spreadsheet looks sufficiently sophisticated.
This is a specific application of knowing whether your tech stack is working. The objective is a dependable enquiry process, not a migration for its own sake.
Before experimenting, preserve a recoverable copy of the current tracker and confirm who may authorise structural changes. Use synthetic enquiries for the rehearsal so you do not expose customer details to a new tool or test account.
Write down the questions the record must answer: who owns the enquiry, what happened most recently, what happens next, and when is it due? If different colleagues give conflicting definitions, settle those before changing software.
A new application can make ambiguous rules harder to see without resolving them. For example, a status called “pending” is not useful unless everyone knows whether it means awaiting the customer, awaiting internal approval or waiting for an assigned colleague.
Make ownership observable
Create a dummy enquiry with one named owner and one dated next action. Ask another team member to take it over using only the record, without a private explanation from its original owner.
Success means the second person can identify what has already happened and continue without sending a duplicate or contradictory response. If they need to search personal inboxes or ask around, the tracker lacks information required for handover.
Ownership should identify responsibility, not imply that nobody else can help. Agree how leave, illness and reassignment work. A visible backup arrangement is more useful than a cell containing the name of somebody currently unavailable.
Test closure too. A completed enquiry should not remain indistinguishable from an unanswered one merely because both have no next-action date. Use a small set of statuses with clear definitions rather than a growing collection of near-synonyms.
If the existing sheet can support these rules and colleagues use them consistently, you have not yet established a reason to leave it. First fix the missing process.
Separate the enquiry from its repeated contacts
An enquiry is one request or opportunity. Contact events are the calls, emails or other interactions that happen while dealing with it. Repeating the full enquiry details in every interaction row creates maintenance work and opportunities for disagreement.
A simple structure might use one enquiry record with a stable identifier and a separate contact history that refers to that identifier. This is a relationship: several contact events belong to one enquiry.
You can design that structure in a spreadsheet, but somebody must maintain valid references and teach colleagues how to use it. Do not call a pair of tabs a dependable database simply because they have matching-looking columns.
Rehearse changing an enquiry's contact address, reassigning its owner and adding a follow-up. Check whether old contact records become confusing or disconnected. Decide which historical facts should remain unchanged and which current details should be read from the enquiry record.
If these distinctions require increasingly fragile formulas or a single expert to repair them, that is a stronger migration signal than row count. The replacement must demonstrably handle the actual relationships, not just display an attractive dashboard.
Calculate the duplication you are maintaining
Consider a team tracking 420 enquiries, each with three recorded follow-up contacts. These are illustrative assumptions. There are 420 × 3 = 1,260 contact rows.
Suppose each contact row repeats four current enquiry-level fields: customer name, reply address, enquiry date and assigned owner. The contact table then contains 1,260 × 4 = 5,040 instances of those fields.
Holding those four fields once per enquiry requires 420 × 4 = 1,680 instances. The difference is 5,040 − 1,680 = 3,360 repeated field instances. Contact-specific details and linking identifiers are additional in either design; the calculation compares only the four repeated fields.
Now assume twelve reply addresses need correction, each repeated across three contact rows. That means 12 × 3 = 36 edits in the duplicated arrangement, against twelve changes to the current enquiry records in the separated arrangement.
At an illustrative thirty seconds to find, change and verify each field, twenty-four avoided edits represent 12 minutes. If checking the relationships adds six minutes that week, the net maintenance release is six minutes, not twelve.
This example does not justify a paid migration by itself. It shows where the burden comes from and what to measure. If colleagues frequently overlook one of the copies, the consequence may matter more than the modest arithmetic saving.
Check access and editing separately
Use the permissions people actually require. If every colleague is allowed to read all enquiry data, shared access may be straightforward. If some cases must be hidden from other team members, prove that the selected system enforces that boundary.
Do not confuse protection against accidental edits with confidentiality. Google explicitly says protected sheets and ranges are not a security measure; people may still copy, print or export protected material. Hiding a sheet is also not an access boundary. See Google's guidance on protected and hidden sheets.
Test concurrent work using dummy records and the team's actual applications. Have two people update different enquiries, then deliberately attempt a handover on the same one. Inspect what survives and whether the team can recognise the current owner and action.
Do not assume another product will solve this merely because it is called a database or customer relationship management system. Verify permissions, edit behaviour and history on the account tier you would buy. A demonstration by an administrator may conceal what ordinary team members experience.
Choose the smallest defensible change
| Option | Record structure | Access requirement | Continuing responsibility |
|---|---|---|---|
| Keep the current sheet | One clear enquiry record with manageable history | Everyone may appropriately see the shared data | A named owner maintains definitions and review habits |
| Restructure the sheet | Separate enquiries and contact events with tested references | Existing sharing boundaries remain adequate | Someone checks references and supports normal edits |
| Move to a verified system | Relationships or workflow cannot be maintained reliably in the sheet | Required permissions must be demonstrated on the proposed tier | Someone owns configuration, migration, export and support |
The table is a decision comparison, not a ranking of product categories. A well-maintained sheet can outperform a poorly configured replacement for this task.
Before approving migration, run the same synthetic enquiry through the proposed system, including handover and export. Confirm what happens to contact history and identifiers in that export. If you cannot understand how you would leave, the proposed improvement brings a new dependency that belongs in the decision.
Make the decision over one working week
- Set aside thirty minutes to define ownership, statuses and next actions. Preserve the current tracker before editing its structure.
- Rehearse a synthetic enquiry through assignment, repeated contact and handover. Note exactly where information becomes ambiguous or inaccessible.
- Over the next working week, record real maintenance effort without copying customer content into the review notes.
- Keep the sheet if the process is dependable. Trial a revised structure if duplication is the main problem, using a copy and an agreed rollback point.
- Investigate a replacement only for requirements the rehearsal shows you cannot safely meet. Stop a migration trial if it exposes data, loses history or depends on an unverified feature.
Related guides
Frequently asked questions
Is there a maximum number of enquiries a spreadsheet should hold?
There is no useful universal editorial threshold for this decision. A row count alone does not reveal whether records are simple, access is appropriate or colleagues can maintain the process. Look at the work needed to find a current enquiry, assign it and understand its history. Repeated corrections, hidden ownership and unreliable relationships matter even in a relatively small collection. Conversely, a larger, uncomplicated tracker may remain manageable. Check the documented technical limits of your actual application if you approach them, but do not treat staying below a product limit as proof that the team's enquiry process is working well.
Should every email become a separate row?
Not automatically. Record the interactions needed to understand and continue the enquiry, using a consistent rule that the team can maintain. A separate contact-history record can be useful when several exchanges change the next action or commitment. Copying every message in full may create unnecessary exposure and maintenance without helping handover. Keep links or references only where the authorised successor can actually access them. If the work requires a complete correspondence record, confirm the appropriate retention and access arrangement for that requirement. Do not assume a spreadsheet summary replaces an existing record-keeping obligation or the original authorised communication system.
Can hidden tabs keep sensitive enquiries away from colleagues?
Do not use hidden tabs as a confidentiality control. A presentation choice and an enforceable access boundary are different things. Determine who is permitted to see the information and select a sharing arrangement that actually reflects that requirement. If only part of the team should access certain enquiries, test the proposed permissions using an ordinary user account, not the administrator's view. Removing names from the visible sheet may also leave identifying information in other fields or history. Where the access requirement is unclear, pause the structural change and ask the responsible manager or data-protection adviser before adding more personal information.
What if one colleague is the only person who understands the formulas?
Treat that dependency as a maintenance problem worth testing, not automatic proof that the spreadsheet must be replaced. Ask another colleague to perform an ordinary update and recover a deliberate mistake in a safe copy using written instructions. If the process depends on undocumented knowledge, simplify the structure or document the essential controls. A new application can reproduce the same dependency around its configuration and automations. Migration becomes more defensible when the current arrangement cannot be made understandable within reasonable effort and the proposed replacement demonstrably supports handover. Include training and ongoing ownership in both options rather than comparing only subscription prices.
Should we migrate old enquiries or start with new ones?
Choose according to the history needed for current work, not a desire to make the new system look full. Some teams need open enquiries and their relevant contacts immediately, while closed material can remain in an authorised, searchable archive. Others need connected history to avoid contacting the same person inconsistently. Define those needs before importing anything. Test a small synthetic or appropriately approved sample, compare record counts and inspect relationships, dates and ownership. Keep a recoverable source copy until the migration is reconciled. Do not delete historical records merely to simplify an import when retention or contractual requirements have not been checked.
Will adding AI make an enquiry spreadsheet easier to manage?
It may help a bounded task, but it will not establish reliable ownership or repair an unclear information structure by itself. First define which output you need and how a person will verify it against the source record. An AI-generated summary that omits a promised deadline can make handover worse even when it reads fluently. Before exposing customer information to an AI service, check the applicable permissions and data terms for the actual account. Use synthetic examples for an initial trial. If a clearer status field or simpler contact history solves the problem, that is usually the more direct first change.
Sources and verification
- Google: Protect, hide and edit sheets, checked on 11 September 2026 for the distinction between editing protection, hidden sheets and security.
- The assigned parent guide was read in the supplied site source. Its public route could not be retrieved during verification; the supplied canonical path is retained. The record examples and arithmetic are illustrative, not measured performance or product limits.
This article is practical guidance. Apply it in proportion to your tools, evidence, risks, and responsibilities.
