Start with a decision, not a dashboard
A dashboard is useful when it helps someone make a decision. Before bringing spreadsheets together, identify the questions the business needs to answer. Which enquiries need follow-up? Which services generate repeat work? Where does the team lose time? Choose a small number of questions and decide who will act on the answers.
For a lean Singapore team, a reliable weekly view can be more valuable than a complex live dashboard. Describe the meeting or working moment where the report will be used. This keeps the scope grounded and helps avoid a collection of attractive charts that nobody checks once the initial excitement has passed.
Agree what each number actually means
Two spreadsheets can use the same label for different things. Sales might mean confirmed orders in one file and paid invoices in another. A customer count might include duplicates, cancelled accounts or multiple contacts from the same organisation. Write down the definition, source and reporting period for each metric before combining the data.
Use consistent dates, currencies and identifiers. Make the treatment of refunds, cancellations and missing values explicit. Where different teams disagree about a definition, resolve that disagreement with the business owner rather than hiding it in a formula. An AI-generated explanation cannot repair a metric whose meaning changes from one worksheet to the next.
Keep cleaning rules repeatable and visible
A one-time cleanup can produce a good-looking report and still leave a fragile process. Record how duplicate records are detected, how dates are normalised and which values are rejected. Preserve the original inputs where appropriate so the team can investigate a surprising result. Prefer consistent, reviewable transformations over manual changes nobody can later explain.
Mark incomplete information instead of silently substituting a reassuring number. A missing value is not always zero, and an unmatched record is not automatically irrelevant. Create a visible place for exceptions to be reviewed. If the source changes, the process should show the problem rather than continuing to generate a confident summary from broken inputs.
Use AI to explain checked calculations
Calculate important totals and comparisons with dependable data tools or database queries. Give the assistant those results and the definitions it needs to explain them. This is safer than asking a language model to infer financial totals from a long pasted spreadsheet. Keep the explanation linked to the reporting period and the underlying figures.
Separate observation from speculation. A report may show that enquiries increased, but it cannot establish the cause without further evidence. Ask for language that distinguishes a measured change from a possible explanation. Review generated summaries for unsupported conclusions, missing context and small sample sizes before using them to make staffing, spending or customer decisions.
Build a small reporting model before joining files
Imagine a fictional service business with an enquiry spreadsheet, a booking spreadsheet and a payment export. Each file records a different event. An enquiry is not yet a booking, and a booking is not necessarily a payment. Keep those events distinct and decide which identifiers connect them. Otherwise, joining the files can turn one enquiry with several line items into several enquiries in the report.
Write down what one row represents in each source: one customer, one enquiry, one booking or one payment transaction. Choose stable identifiers rather than relying on names that can be misspelled or shared by different people. Where a reliable identifier is missing, create an exception for review instead of assuming that two similar names must represent the same record.
Start with a few metrics the team can explain, such as enquiries received, bookings confirmed and payments collected for a defined period. Show the reporting date and the source refresh time. A small report with clear boundaries is easier to trust than a broad dashboard built from joins whose meaning nobody can describe.
Prevent quiet errors in dates, joins and missing values
Dates deserve explicit treatment when files come from different systems. A value such as 05/03/2026 can mean 5 March or 3 May depending on the source convention. Record that convention before conversion and use an unambiguous date representation in the combined data. Preserve the original value for investigation. Display formatting alone cannot correct a date that was interpreted incorrectly during import.
Check row counts and totals before and after joining. A one-to-many relationship can legitimately increase rows, but the increase should not multiply a metric intended to count distinct enquiries. Keep cancelled records and refunds visible under the agreed definitions. If the reporting process rejects a record, retain the reason and give someone responsibility for resolving it.
Distinguish an actual zero from unknown information. A blank payment field might mean unpaid, not yet imported or missing from the export. Those cases support different decisions. Establish the meaning with the source owner rather than asking an assistant to guess. Use a reconciliation check against a trusted source total so unexpected differences are investigated before a narrative is generated.
Explain a change without inventing the reason
Suppose checked records show 180 enquiries and 54 bookings in one month, followed by 210 enquiries and 63 bookings in the next. Enquiries rose by about 16.7%, while the booking rate stayed at 30% in both periods. If these bookings are linked to the enquiry cohort for each month, the report can say that more enquiries produced more bookings at the same observed conversion rate. It should not claim that sales effectiveness improved simply because the booking total increased.
If the files instead count all enquiries and all bookings occurring within each calendar month, those totals may include bookings from earlier enquiries. In that case, dividing one by the other does not necessarily measure enquiry conversion. This is why metric definitions and timing matter as much as the arithmetic. Ask the assistant to explain the defined measure rather than assign a familiar label to whatever totals happen to be available.
Give the summary a next action that matches the evidence. The team might compare enquiry sources, check available appointment capacity or examine unresolved enquiries. A campaign is only a possible explanation until supporting records establish it. Useful reporting makes the next investigation clearer while keeping observed facts separate from assumptions.
Give the report an owner and an action loop
Name the person who checks the report, maintains the definitions and resolves source problems. Agree when the data is refreshed and how users can tell whether a report is current. Restrict access to personal or commercially sensitive records even when a high-level chart is shared more broadly. A summary does not automatically make its underlying information safe to distribute.
End each review with a small set of actions and revisit them at the next meeting. If a chart never changes a decision, consider removing it. Useful reporting should reduce uncertainty and make follow-through easier. AI can help describe the pattern, but a trustworthy process depends on clear definitions, traceable calculations and people willing to act on the evidence.
