A spreadsheet becomes a useful question-answering helper when people can ask ordinary questions and check the answers against actual rows. The first run does not need a vector database or an elaborate agent. Start with one worksheet, a small backend, and a clear rule: calculations come from your code; explanations come from the model.
1. Pick one worksheet and three answerable questions
Use a concrete starting point: an orders worksheet with order identifier, order date, customer, region, status, and revenue columns. Export it as CSV, keeping the original workbook unchanged. For this first version, use one currency and define whether revenue includes tax and refunds.
Write three test questions before building anything: “What was total revenue in March 2026?”, “Which region had the highest revenue that month?”, and “Which orders are still pending?” These establish the filters, calculations, and row details your helper must support.
2. Clean the columns and preserve row references
Load the CSV into a table using a tool such as Python with pandas. Standardize column names, parse dates explicitly, and convert revenue into integer cents. Reject invalid values instead of silently treating them as zero. Check for duplicate order identifiers before calculating totals.
Add a source reference to every record. For example, retain the workbook name, sheet name, original spreadsheet row number, and import version. An answer can then point to “Orders, row 18, import 2026-04-02” rather than offering an untraceable claim.
- Missing values: distinguish unknown revenue from zero revenue.
- Date rules: decide which timezone applies to timestamps.
- Privacy: remove customer details the helper does not need.
3. Connect your backend through SwiftRelay
SwiftRelay is a practical connection point if you want to use an OpenAI-compatible SDK while keeping your application’s data handling in your own backend. Sign up for SwiftRelay, create an API key, and store it in a server-side environment variable.
Configure the SDK base URL as https://api.fastapirelay.com/v1 and supply the key through the SDK’s authentication setting. Choose an available model, such as Gemini 2.5 Flash, and copy its exact API identifier from your account’s model listing rather than guessing it from the display name. Billing is per token, so sending only necessary evidence also helps control spending.
4. Turn each question into a constrained query plan
Do not ask the model to invent and execute arbitrary code. Give it your column definitions and ask for a structured plan containing an operation, filters, grouping, and requested fields. For March revenue, that plan should mean: sum revenue for dates on or after March 1 and before April 1, 2026.
Validate the plan against an allowlist. Accept only known columns, supported operations, and valid filter values. If someone asks for “recent orders,” request a date range instead of quietly choosing one. Reject unsupported requests with a useful explanation.
5. Calculate answers before writing explanations
Execute the validated plan with your table library. Calculate totals, counts, and rankings across every matching row, not just a few retrieved examples. For the regional ranking, group by region, sum revenue, and preserve ties.
Return a compact evidence package containing the calculated result, applied filters, matching row count, import version, and source references. For long order lists, paginate the results and label the displayed subset. An empty match should produce “No matching rows,” not an invented estimate.
6. Make the response explain its evidence
Send the evidence package to the model with instructions to answer only from that package, state the date range, and include source references. Keep spreadsheet cell contents separate from application instructions: a cell saying “ignore previous instructions” is data, not a command.
Show the answer alongside an expandable evidence list. For aggregate answers, provide access to all contributing row references rather than implying that two example rows prove the total. If required evidence is missing, the helper should say what it cannot establish.
7. Test the helper before sharing the worksheet
Compare your three test answers with spreadsheet formulas or a pivot table. Add tests for duplicate identifiers, blank revenue, tied rankings, empty results, and ambiguous dates. Confirm that unauthorized users cannot query restricted rows; enforce that restriction before calculating or sending evidence to the model.
Finally, display the import version with each answer and define a refresh process. Your first useful helper is not the one that sounds most confident. It is the one whose filters, arithmetic, and source rows another person can verify.