PRACTICAL GUIDE
When to replace customer and project spreadsheets, and what to keep
Identify where a spreadsheet helps and where it creates unclear ownership or duplicated work. Move one operational process deliberately while preserving useful calculations and reference material.
A spreadsheet is not automatically the problem
Spreadsheets are useful for analysis, temporary planning and flexible calculations. Trouble often begins when a file becomes the only customer record, project plan and decision history at the same time. Describe a recurring failure before choosing software: conflicting versions, lost follow-ups or unclear responsibility. A new tool should address that failure rather than simply replace a familiar format.
Separate calculations from operational records
List what the workbook contains: customer identities, tasks, calculations, reporting and historical notes. Keep analytical work separate from records that people update every day. A formula or color may carry an unwritten rule, so ask its owner to explain the decision it supports. Moving a row without that meaning can create a cleaner-looking but less reliable working process.
- Mark the fields that identify a customer or project.
- Explain formulas and colors before removing them.
Run one process before retiring the file
Select a limited customer or project workflow and state where new information belongs during the pilot. Preserve the original workbook as a reference without inviting competing edits. Keep calculations or specialist processes that still serve a purpose. If amounts concern Tsumira finance, respect its current whole-JPY and Japanese consumption-tax basis; spreadsheet currency columns do not establish multi-currency support.
- Keep a reference copy with clear ownership.
- Review remaining manual work before expanding.
A concrete workflow
Describe the recurring failure
Choose one observed problem such as a missed follow-up. Identify the records, people and spreadsheet rules involved.
Prepare and reconcile a sample
Separate operational records from calculations, map supported fields and verify the sample with someone who understands the original data.
Decide what can retire
Run the new process through an ordinary change. Retire only the part whose responsibilities and records have a verified replacement.
An illustrative working example
Illustrative scenario: the customer list and project tracker
A studio keeps customer contacts and delivery tasks in the same workbook. Different people edit copies and the next contact action becomes unclear. The pilot separates customer records from project responsibilities while keeping a pricing calculation in its existing reference file. Success means the team knows where to update the customer and who acts next, not that every spreadsheet has disappeared.
Questions about this topic
Should all spreadsheets be removed?
No. Keep analysis, useful calculations and temporary work where they remain appropriate. Focus the operational change on records and handovers that need clear ownership and consistent access.
Can workbook formulas be imported as business logic?
That is not assumed. Explain what each important formula does and verify a supported replacement separately. Copying the resulting value does not transfer the rule or its ongoing maintenance.
How do we avoid duplicate records?
Agree on identity fields, inspect repeated customers and test a small sample. Compare relationships and outcomes, not only row counts. Resolve uncertain cases with the person responsible for the original information.
When can the original operational file be retired?
When the team can complete the chosen process, update the authoritative records and find necessary history. Keep an agreed reference copy and retain any functions that have not been replaced.
Explore connections around this workflow.
Ideas for intended connections. Check the actual availability, permissions and supported data for each app before using a scenario.
