How to Build a Financial Report in 30 Seconds Using Chat

The average finance team spends 8 to 12 hours per week building reports. Not analyzing data. Not making decisions. Building reports. Opening a BI tool, writing queries, dragging columns into the right order, formatting cells, exporting to PDF, emailing it to someone who will glance at it once before the numbers are already stale.

This is not a workflow problem. It is an architecture problem. Reports take forever because the tools were designed around a different assumption: that humans should construct the output format manually. Change that assumption, and reporting collapses from hours to seconds.

What Reporting Looks Like Today

Walk into any finance team at a company doing $1M to $50M in revenue. You will find some combination of the following:

A BI tool that three people know how to use. A spreadsheet that one person maintains and everyone else copies from. A recurring Monday morning where someone manually pulls numbers, formats them, and sends a Slack message or email. A quarterly board deck that takes a full week to assemble.

The tools vary. Could be Metabase, Looker, or just raw SQL against a production database. The pattern does not. Someone translates a business question into a technical query, waits for the result, reformats it for the audience, and distributes it. Every step is manual. Every step introduces latency and the possibility of error.

The painful part is that the business question itself is usually simple. "What was revenue by client last quarter?" "Which invoices are overdue?" "How do expenses this quarter compare to last quarter?" These are not complex analytical problems. They are retrieval problems wrapped in formatting labor.

The 30-Second Version

In Well, you type the question. You get the answer.

That is the entire workflow. Here is what it looks like in practice:

Query: "Show me monthly revenue by client for Q4"

The system returns a chart. Bar chart, clients on the x-axis, months grouped, revenue on the y-axis. No configuration required. No drag-and-drop. No SQL.

Query: "Show overdue invoices"

The system returns a grid. Columns for client name, invoice number, amount, due date, days overdue. Sorted by days overdue, descending. Filterable, sortable, exportable.

Query: "Why did margins drop?"

The system returns text. A written explanation identifying the contributing factors: increased cost of goods in a specific category, a client discount that was applied retroactively, seasonal revenue decline in one segment. It cites the numbers. It does not guess.

Query: "Compare Q3 vs Q4 expenses by category"

The system returns a grouped bar chart. Q3 and Q4 side by side for each expense category. The categories where spending increased are immediately visible.

Each of these takes less than 30 seconds from typing to seeing the result. Most take under 10.

How the AI Picks the Right Format

The speed comes from a system we call AI Response Modality. When you ask a question, the AI does not just retrieve data. It decides how to present it.

There are three rendering paths:

Text is used when the answer requires explanation, context, or narrative. "Why did margins drop?" is a text question because the answer is causal, not tabular. The AI needs to identify relationships between data points and explain them in sequence.

Grid is used when the answer is a list or a table. "Show overdue invoices" is a grid question because the user needs to see individual records with multiple attributes. Grids support sorting, filtering, and export.

Chart is used when the answer involves trends, comparisons, or distributions. "Monthly revenue by client" is a chart question because the user is looking for patterns across time or categories. The AI selects the chart type (bar, line, pie) based on the data shape.

The AI makes this decision automatically. You do not tell it what format to use. You ask a question in natural language, and the system infers the appropriate output. This is not a template system where you pick "report type A" or "dashboard widget B." The modality selection happens at query time based on the structure of your data and the intent of your question.

This matters because it removes the formatting step entirely. In traditional reporting, you spend as much time deciding how to present data as you do retrieving it. Should this be a table or a chart? What chart type? What goes on which axis? These decisions are now made by the AI, and in our testing, it picks the right format about 90% of the time. When it does not, you can override it.

Saving and Reusing Reports

A one-off query is useful. A saved view is a tool.

When you get a result you want to keep, you save it to the canvas. The canvas is where your persistent views live. Think of it as a personal dashboard you build by asking questions. Each saved view retains its query, its data connection, and its format. When the underlying data changes, the view updates.

This turns ad hoc questions into standing reports. Save "monthly revenue by client" once, and you have a live revenue report on your canvas. Save "overdue invoices" and you have an aging report that updates every time you open it.

You can organize canvas views, share them with teammates, and use them as the basis for recurring workflows.

From Chat to Recurring Workflow

The jump from "ask a question" to "automate a report" is one step.

Chat-to-workflow lets you take any query and schedule it. "Send me the overdue invoices report every Monday at 9am." That is the entire setup. The system runs the query on schedule, renders the result, and delivers it wherever you specify: email, Slack, or within Well itself.

This replaces the Monday morning ritual where someone manually pulls numbers and distributes them. The report runs itself. If the data changes between Monday and Tuesday, the next scheduled run reflects it. If you need it sooner, you just ask the question again in chat.

For recurring board reports, you save a set of queries to canvas and schedule them as a package. The board deck that used to take a week now assembles itself from live data.

What "30 Seconds" Actually Requires

The 30-second report is real, but it has prerequisites.

First, your data needs to be in Well. The system queries structured data that has been connected and mapped. If your financial data lives in QuickBooks, Xero, or a bank feed, it needs to be synced into Well before you can query it conversationally. The setup time for connecting a data source varies. Some integrations take minutes. Others require mapping fields and verifying that the sync is accurate.

Second, data quality matters. If your books are messy, the reports will reflect that mess accurately. The AI does not clean your data. It queries what is there. "Show me revenue by client" will return wrong numbers if revenue is miscategorized or clients are duplicated. The speed of reporting amplifies whatever state your data is in, good or bad.

Third, not every question has a simple answer. "Why did margins drop?" works when the contributing factors are identifiable in the data. If margins dropped because of a verbal agreement that was never recorded in the system, the AI will not know about it. It operates on the data it can see.

These are not dealbreakers. They are the same constraints that apply to any reporting tool. The difference is that traditional tools hide these problems behind a long build process. By the time you discover the data is wrong, you have already spent hours on the report. With chat-based reporting, you find out in 30 seconds.

Why This Matters for Small and Mid-Size Companies

Large enterprises have data teams. They have analysts whose job is to build and maintain reports. They can absorb the overhead of traditional BI tools because they have dedicated headcount for it.

Companies doing $1M to $50M usually do not. The person building reports is also the person running payroll, managing vendors, or closing the books. Every hour spent building a report is an hour not spent on the work that actually moves the business forward.

Self-serve analytics has been a promise for a decade. Most tools that claim it still require training, configuration, and ongoing maintenance. The bar for "self-serve" in practice has been: can you use it after a two-day onboarding? That is not self-serve. That is a smaller learning curve.

Actual self-serve means asking a question in English and getting an answer. No training. No onboarding. No query language. The person who needs the data gets the data, without filing a ticket or waiting for someone with access to the BI tool.

This changes the relationship between a company and its financial data. When reports are hard to build, people build fewer of them. They check the numbers monthly instead of weekly. They make decisions based on gut feel because pulling the actual data takes too long. When a report takes 30 seconds, you check the numbers whenever you have a question. Decisions get faster. Surprises get rarer.

The Shift

Financial reporting has been a production process: gather, build, format, distribute. Each step takes time, requires specific skills, and introduces delay between the question and the answer.

Chat-based reporting compresses that entire process into a single interaction. You ask. You see. You decide.

The 30-second report is not a feature. It is what happens when the architecture stops assuming that humans should manually construct every output. Structure the data, let the AI handle the format, and the report builds itself.

The question is not whether this is faster. It is what you do with the time you get back.