Spreadsheets can be a useful starting point for AI or automation. Sales history, order records and service logs may contain information that supports a focused business question. A data warehouse is not a prerequisite for every project.
The file format does not establish whether the data are sufficient. Useful information must be relevant, reliable and available in the form needed for the task. Sometimes the next step is a predictive model; sometimes it is better reporting, a rules-based workflow or improved data collection.
Distinguish the kinds of work
Training a large foundation model from scratch, adapting an existing model and analysing business records have different requirements.
A forecasting or classification model learns from examples relevant to its target. A RAG system retrieves material from a document collection to help an existing model answer questions. A reporting workflow may need no machine learning at all.
Fine-tuning is another method, used where suitable examples and a clear evaluation justify it. There is no universal number of examples that guarantees a useful result for any of these approaches.
Check what the spreadsheets actually contain
A useful inventory records the source, owner, meaning, update frequency and access rules for each dataset. For tables, check what one row represents and whether identifiers remain consistent across files.
Ask:
- Are dates, units and categories recorded consistently?
- Can customers, orders or assets be linked without ambiguous matches?
- Have definitions or operating practices changed over time?
- Are relevant outcomes recorded, including unsuccessful or exceptional cases?
- Are personal or confidential data involved, and may they be used for this purpose?
- Can the same inputs be obtained when the system is running?
A manually maintained sheet can contain valuable business context. It can also contain overwritten history, hidden formulas, duplicated records or values filled in after an outcome became known. Inspect those details before using the sheet as training data.
Five possible uses and what to investigate
Demand forecasting
Order history can support a demand forecast where the time series captures relevant patterns. Check stockouts, promotions, discontinued products and changes in how orders were recorded.
Compare against a simple baseline, such as the previous comparable period. Use a time-based evaluation that reflects the forecast horizon. A single percentage called “accuracy” can be misleading for forecasting; select measures that fit the quantities and business decision.
The amount of history needed depends on the patterns being estimated. One annual cycle is not a universal guarantee that annual seasonality can be learned reliably.
Document and email classification
Folders, tags and routing decisions may provide labels, but they need checking for consistency. Define the categories and how to handle ambiguous or unfamiliar documents.
Evaluate errors by category, including rare but consequential cases. An overall accuracy score can look strong while the system misses a small class that matters. A model-assisted routing workflow may need a human review queue for uncertain cases.
Questions over internal documentation
A retrieval-based assistant can use a small, well-maintained document collection. The number of files alone does not determine quality: coverage, freshness, contradictions and access permissions matter.
Test whether answers are supported by the sources and whether the system declines questions the material cannot answer. Adding more documents can introduce duplication or conflicting information as well as useful coverage.
Report preparation
Reliable exports and agreed definitions can support automated calculations and formatting. If an AI model writes commentary, check its statements against the calculated values and source records.
Keep authoritative calculations in an appropriate deterministic workflow. Generated prose should not become the sole source of financial totals or other figures that require exact reproducibility.
Anomaly detection
Logs or measurements can help identify unusual behaviour. An unusual observation is not automatically a fault or fraud, and a familiar pattern is not automatically safe.
Assess false alerts, missed events and how people will investigate flagged cases. Labels may not be required to fit some anomaly-detection methods, but evidence about real outcomes is still valuable for evaluating whether the alerts help.
A four-step route from spreadsheet to a working system
1. Define one use case and its baseline
Choose a decision or process with an owner and an observable outcome. Document how it works today, what a better result would mean and what errors would cost.
The initial question should be narrow enough to test. “Which customers should an account manager review this week?” is more actionable than “use AI across sales”.
2. Prepare a relevant dataset
Preserve the original files and record cleaning rules. Standardise identifiers and dates, investigate missing values and remove duplicates where justified. Do not silently discard difficult cases that the future system will need to handle.
Use only information that would be available at the moment of prediction or decision. Fit preprocessing steps using training data rather than allowing test data to influence feature selection, scaling or imputation.
3. Test against the baseline
Select a validation design that reflects deployment. Time-dependent work usually needs a chronological split or rolling evaluation. Where repeated records from the same customer or asset could create leakage, account for those groups as well.
Compare a simple method with more complex alternatives. Evaluate uncertainty and error patterns, not just the best score from repeated experiments. Keep an untouched test set where appropriate and avoid tuning the model to it.
A useful result can be a decision to proceed, change the scope or improve data collection first. A pilot is not obliged to justify the original idea.
4. Build operation around the result
Production work includes data ingestion, permissions, user interaction, monitoring, recovery and documentation. Define who owns failures and how the system can fall back to an acceptable manual process.
Monitor the input data and the outcomes that can be measured. Changes in products, customers or policy may invalidate earlier assumptions. Review the system when evidence warrants it; automatic retraining on a calendar is not a complete maintenance strategy.
Hypothetical example: reviewing customer churn risk
Consider a service business with separate spreadsheets for customers, invoices and complaints. This is an illustrative scenario, not a QA10 client case or a claim of measured results.
The team wants to identify customers who may stop buying within a defined future period. It first defines what “leaving” means and whether the records contain enough completed outcomes to evaluate that question.
For each historical prediction date, the team constructs features using only information available at that date: recent order frequency, invoice history and unresolved complaints. Later events are reserved for the outcome label. A complaint closed after the prediction date cannot be treated as if its resolution were already known.
The evaluation uses earlier periods for training and later periods for testing, with additional safeguards for repeated customer records where needed. It compares the model with a simple existing rule and examines precision, recall and the workload created for account managers.
A useful prediction still does not prove that contacting the customer improves retention. The business needs a suitable evaluation of the intervention. Any financial estimate should use incremental contribution and costs, rather than treating all retained revenue as profit.
When to improve the data first
Pause when the target cannot be defined, the sample is unrepresentative, important history has been overwritten or the outcome is too rare to evaluate responsibly. A large row count does not fix these problems.
Data collection may be the appropriate first deliverable: stable identifiers, consistent event records, clearer categories or a feedback process. Define what evidence the collection should produce before promising that a fixed number of weeks will make the data sufficient.
An existing model or a rules-based workflow may still help with a different part of the process. The absence of a suitable predictive dataset does not establish that every form of automation is impossible.
Discuss the next step
Q-Journey starts with an audit of the organisation’s needs and processes and can continue into software delivery, with or without AI. AiP is part of Q-Journey, with Express and Platinum options; Platinum also includes Lean and Muda consulting. The scope and schedule are agreed individually.
Where fine-tuning is appropriate, QA10 performs it on its own GPU infrastructure. That instance is not provided to the client. Deployment can use the client’s hardware or cloud account, with advice and configuration support; the client is responsible for maintaining its instance. Discuss your data and process.
FAQ
Can an Excel file be a useful source for AI?
Yes. Its usefulness depends on the meaning, quality, history and permitted use of the data, not simply the file format. A spreadsheet may support a focused experiment, but it does not guarantee a successful model.
How many records do we need?
There is no universal minimum. The task, variation, outcome frequency, data quality and evaluation requirements matter. Inspect a representative sample and test whether it supports the intended decision.
Do we need a data scientist on staff?
That depends on the work and the organisation’s ongoing responsibilities. An external team can provide specialist skills, while an internal process owner is still needed. Decide who will maintain the data, evaluate results and operate the system.
How much will the project cost and how long will it take?
Cost and schedule depend on the use case, data preparation, integrations, evaluation and operating requirements. A spreadsheet-based starting point alone does not determine either. Agree the scope and assumptions before estimating delivery.
Does a higher model score guarantee business value?
No. The score must reflect the intended task, and the workflow must use the output effectively. Compare against the current method, investigate errors and measure the effects of the resulting decisions.