Many Nepali businesses have data in spreadsheets, POS exports, branch files, and support tools. The issue is not always missing data. The issue is the time it takes to turn data into a short answer.

A good reporting pilot starts with a report someone already prepares by hand. If a manager asks for the same weekly sales note, stock exception list, or branch update every week, that is a strong candidate.

Start with one question

Do not build a dashboard for every metric first. Pick one question: which branch is behind target, which stock is low, which support topic rose this week, or which product line slowed down?

Write the question on one line. Then write the exact data needed to answer it. A branch sales question may need date, branch, target, actual sales, returns, and staff notes. A stock question may need SKU, current stock, minimum stock, transfer quantity, and last sale date.

If the data needed for the answer is not collected today, the pilot will not fix that. Start by collecting the missing field or choose a report with better source data.

Choose the source files

Source data may come from a POS export, Google Sheet, accounting file, CRM, support inbox, or branch email. List each source and who owns it. If two sources disagree, decide which one wins before the report is built.

Keep the first report on a fixed schedule. Weekly reports are easier to check than real-time dashboards. A weekly flow gives staff time to find missing data, correct odd rows, and compare the AI draft against the old report.

Clean names and dates

Reports fail when branch names, product names, dates, and staff names are written in many ways. Fix those fields before asking AI to summarize anything.

Use one naming rule. If a branch appears as "Lalitpur", "Patan", and "LTP", choose one label. If products have old names and new names, keep a mapping file. If dates arrive in multiple formats, convert them before summary.

Small naming errors create large reporting errors. A report cannot compare branch totals if one branch has four spellings.

Use AI for summaries

AI can draft a weekly note from a table: what changed, what is missing, and which rows need review. It should link back to the source rows so staff can check the answer.

The first summary should use a fixed structure. For example: total sales, biggest branch change, stock items below threshold, missing branch files, and questions for review. Keep the structure the same each week so staff can spot errors.

Review rule

AI should not be the final source for finance or board reports. Use it to prepare a draft and catch missing data.

Make errors visible

A useful report says when data is missing. If five branches did not submit files, the report should say that before it compares totals.

Missing data should have its own section. Do not bury it in a footnote. If stock data is missing for Pokhara, the report should say that before it recommends a transfer. If support data is missing for one channel, the trend note should say which channel is absent.

Add a human review step

The reviewer should see the source table, the AI summary, and the error list. The reviewer should be able to correct the summary or send it back for data repair. This is especially needed for finance, board, investor, and regulatory reports.

For internal weekly reports, review can be light. For external reports, review should be stricter. The pilot should separate those paths from the start.

Measure prep time

Track how long the old report took and how long the AI-assisted report takes after review. If review takes longer than the old process, narrow the report.

Measure the full path, including draft time. Include data collection, cleaning, summary, review, correction, and sending. AI can draft in seconds, but the project only helps if the full reviewed report is faster or more consistent.

What to review weekly

Each week, look at the same four things: missing data, wrong summary, bad source rows, and unclear wording. Fix the source first. Then fix the prompt or report structure. Do not add more charts while the basic report still has errors.

When a dashboard makes sense

A dashboard makes sense after the weekly report is stable. If the source fields are clean and staff trust the weekly summary, then a dashboard can show live numbers or near-live numbers. If the weekly report is still wrong, a dashboard will show wrong numbers faster.

The first reporting pilot should answer one management question and reduce report prep time. That is enough. More charts can come after the data and review path work.