Use a Google Sheets CRM when the team can maintain a clear contact register, named follow-up ownership and consistent entry rules. Decide who may access the spreadsheet separately from who may edit particular cells. Prepare a migration map early, and judge suitability by the enquiry handover the team can actually complete.
Start with a missed or unclear follow-up rather than a template’s appearance. Ask what the next colleague needs to see: the contact, the latest relevant interaction, the owner and the next action. Make those meanings explicit before adding formula columns, status labels or shared tabs.
How should the shared register describe the work?
Propose a stable contact reference and keep it separate from the display name. Decide whether organisations and individual people need separate records, then show how an interaction refers to its intended contact. This makes the future migration discussion concrete and helps colleagues avoid creating another record simply because a familiar name is written differently.
Give every active follow-up an owner the team can identify. Write the next action in terms another colleague can understand, such as requesting the missing brief or confirming the agreed meeting route. A vague note like “follow up” leaves the next person to reconstruct the intended work from memory.
Keep a short field dictionary alongside the design. Define what each status means, who changes it and what evidence supports that change. Choose the fields needed for the workflow rather than treating every available detail as something that belongs in the shared register.
Google’s dropdown documentation gives a useful consistency mechanism. A dropdown can obtain its options from a range. Dropdown values can also be entered directly. Pick the route the register owner can maintain, and record who approves changes to the shared vocabulary.
What should validation do when someone enters an unexpected value?
A dropdown rule can reject an entry that is not on its list. Invalid dropdown input can instead be configured to show a warning. Decide which behaviour fits each field, then demonstrate it with the people who enter the data. The presence of a dropdown does not tell the reviewer which invalid-input behaviour is active.
Use rejection where the workflow needs the controlled vocabulary and an exception route exists. A warning may suit a field that deliberately allows reviewable exceptions. Write the intended consequence in the requirements so a colleague knows whether to correct the entry, request a new option or explain why the exception is needed.
Multiple dropdown selections are not currently supported on mobile. If field staff or travelling colleagues will use the register, include their intended device in the demonstration. A convenient desktop configuration should be assessed against the actual working arrangement before it becomes a dependency in the process.
| Register question | Proposed decision | Evidence to request |
|---|---|---|
| Is this the same contact? | Stable contact reference | A changed display name retains the intended relationships |
| Who acts next? | Named follow-up owner | Another colleague identifies the owner without explanation |
| Which status is valid? | Agreed option list and invalid-input rule | An unexpected sample value is handled as specified |
| Who maintains formulas? | Explicit edit responsibility | Ordinary entry remains usable under the intended controls |
| Can the data move later? | Field dictionary and relationship map | Sample contacts and activities map into the destination structure |
The table is an original acceptance worksheet. It combines entry behaviour with the meaning of the information being entered. A controlled list is most useful when colleagues also agree what its options mean and who handles an exception.
How do range protection and sharing responsibilities differ?
Google’s protection guidance explains the boundary. Google says spreadsheet protection should not be treated as a security measure. People can copy and export protected spreadsheet content. Make the decision about who receives access to the register before discussing controls intended to reduce editing mistakes.
A protected-range edit warning does not block editing. Custom range permissions can restrict editing to selected people. Show the relevant configuration and the observed result in the demonstration, because the same-looking range may be governed by different choices. Keep the owner’s and editors’ roles explicit in the handover.
All spreadsheet editors can unhide hidden sheets. Decide what the spreadsheet’s intended audience is permitted to know, rather than placing sensitive material on another tab and treating its visibility setting as an access design. Give restricted information an appropriately reviewed storage and sharing route.
Agree how the team maintains one authoritative register. Record who can change its structure, who reviews sharing and what happens when someone leaves the workflow. A change in responsibility should include the open follow-ups, not merely the removal of a colleague’s name from a list.
What should a later CRM migration preserve?
Map the contact reference, organisation, activity history and follow-up owner to the intended destination’s actual fields. Record a sample value beside each mapping and identify any field whose meaning does not transfer clearly. Resolve ambiguous statuses before importing them into a system that may trigger further actions.
Review duplicate and incomplete records with the business owner. Decide which record is authoritative and retain the reason for any consolidation. Keep that review distinguishable from the technical import so a clean transfer does not conceal an unresolved data decision.
Use operating friction to assess whether migration is needed. Repeated uncertainty about ownership, competing copies or missing activity context are useful findings to investigate. Avoid declaring a universal contact-count threshold; the right decision depends on the actual workflow and its maintenance burden.
Original shared-enquiry and migration exercise
Prepare a fictional enquiry from River Projects in a separate test spreadsheet. Include a contact reference, an initial interaction and an assigned next action. The exercise follows a handover, an invalid status entry and a proposed migration mapping using approved sample information.
Ask one participant to record the enquiry and another to identify who acts next. Record the fields they consult and any meaning they cannot determine. Then enter an unexpected status value through the intended interface and inspect whether the configured rejection or warning matches the requirement.
Next, change the sample contact’s display name while retaining its reference. Follow the associated activity and owner, then map the same sample into the proposed CRM structure. Record missing destinations, ambiguous values and relationships that need explicit handling.
Finally, review the worksheet with the register owner and the colleagues using it. Assign each correction and retain the field dictionary with the tested spreadsheet version. Use those findings to decide whether the shared register fits the work and what a future migration must preserve.
For wider scope, see business systems and software development. Get started with your enquiry handover, sharing arrangement and migration questions.
By Spout Team. AI-assisted drafting by Codex using the linked primary documentation.