AI for business · AI reporting

Stop requesting reports. Ask your data.

We add a chat to your existing application that answers questions from the data already in it. "Who are our top five sales people this month?" comes back as an answer, a table or a CSV in seconds, instead of a custom report request that waits in a developer's queue. Read-only, scoped to what each user is allowed to see, and logged.

Ask about adding it to your system How it works
  • Your existing appAdded to the Laravel application you already run, using the data already in it.
  • Read-onlyA direct connection between the model and your database that can only ever read.
  • Scoped by permissionsEach user can only ask about the data they're already allowed to see.
  • Every question loggedWho asked what, the query that ran and what came back, kept for audit.
Why ask instead of report?

Most report requests are a question someone needed answered once

Every business system accumulates a backlog of "can you build me a report that…". Each one takes developer time, and half are only ever run once. Letting people ask the question directly clears most of that backlog, and keeps the developers for the reports that genuinely need building.

"Which jobs went over budget?"

  • ×Email the request, wait for it to be scoped and scheduled

  • ×A developer writes the query and builds the screen

  • ×The report arrives, and now you want it by region

  • ×Someone re-runs and emails it every Monday

Ask in plain language

No query builder, no filters to learn. Questions the way you'd ask a colleague, with follow-ups that build on the last answer.

Answers you can use

A sentence, a table, a chart, a CSV for the spreadsheet or a PDF for the board pack, whichever the question needs.

Schedule the ones that repeat

Any question can become a standing report: every Monday, first of the month, or when a threshold is crossed, delivered to your inbox.

Safe by construction

Read-only access, scoped to each user's permissions, with every question and the exact query it ran written to an audit log.

Example questions

The kinds of things people ask once it's there

Every one of these would once have been a report request. Each is answered from the tables the person already has access to.

Sales

"Generate a CSV of the top five sales employees over the last month."

Ranked by invoiced value, with invoice counts and the change on the month before. Download the CSV, or ask for it as a PDF with a chart for the sales meeting.

Finance

"Send me clients with invoices outstanding more than 30 days, every Monday."

Scheduled, so the chase list lands in your inbox at 8am each week with amounts and days overdue.

Operations

"Which jobs scheduled this week don't have a driver assigned?"

A live list, with the depot and pickup time, so the gap is closed before Monday morning.

Customers

"Which customers ordered last year but haven't this year?"

Lapsed accounts with their last order date and value, ready for a follow-up call list.

Stock

"What's below reorder level, and who's the supplier?"

Current stock against thresholds, grouped by supplier so one email covers each order.

Service

"How did our average response time change month on month, by team?"

A table and a trend chart, then "which tickets took longest?" as the follow-up, all from the support data already in the system.

What's the report you keep asking for?

Tell us the question, and which system holds the answer. We'll show you what it looks like to just ask, on your own data, before you commit to anything.

Bring us a question
How it works

A direct line from the question to your database, with a guard on every step

The model never sees your whole database and never writes to it. It's given the shape of the data a user is allowed to see, turns the question into a query, and the query runs under strict limits before anything comes back.

01

The question

A user types a question in the chat inside your application. Their identity and permissions travel with it.

02

The query

The model is shown only the tables and columns that user can access, and writes a read-only query. Anything that isn't a read is rejected before it runs.

03

The run

The query executes on a read-only database connection, scoped to the user's records, with row limits and timeouts. The question, query and result are written to the audit log.

04

The answer

Results come back as a sentence, table or chart, with CSV and PDF a click away. "Schedule this" turns it into a standing report.

Guardrails

Read-only. Scoped. Logged. Private.

A language model connected to a production database needs a connection built to be safe from the start. This is how ours works.

  • Read-only access. The database connection the model uses cannot insert, update or delete, no matter what it's asked.
  • Permissions enforced. Each query runs as the user who asked, scoped to the records and columns their role already allows. The model is never shown more.
  • Audit log. Every question, the generated query, its result and who asked are recorded, so any answer can be traced and reproduced later.
  • Your data stays yours. It isn't used to train models and doesn't leave an environment you control. Only the schema and the rows needed for the answer are ever processed.
  • Limits and timeouts. Row caps, query time limits and rate limits keep a careless question from becoming a load problem.
How we approach AI in business software
Monitoring dashboard Logged and monitored
Outputs and schedules

An answer, a file, or a report that arrives every week

In the chat

A plain answer, a table or a chart, with the follow-up question one message away. "Now by region." "Only the ones over $10k."

As a file

CSV for the spreadsheet people, PDF for the board pack, formatted with your logo and the question that produced it.

On a schedule

"Every Monday at 8", "the first of the month", "whenever stock drops below reorder". Delivered by email, Slack or into the app, until you say stop.

Good questions

Things people ask before they let staff ask the data

Can't see yours? Ask us directly.

Can it change or delete data?

No. The model works through a database connection that is read-only at the database level, and generated queries are checked before they run. It can't be talked into writing, because the connection physically can't.

Could someone see data they shouldn't?

Each question runs with the asking user's own permissions. The model is only shown the tables and columns that user can access, and the query is scoped to their records. A sales rep asking about "all invoices" gets their invoices, the same as they would on any other screen.

How do we know the answer is right?

The answer comes from a real query against your real data, not the model's memory, and the query is shown alongside the result for anyone who wants to check it. We validate against known reports during setup, and the audit log makes any answer reproducible.

Does it work with our existing Laravel application?

That's the typical case. It's added to the application you already run, using your existing users, roles and database. Laravel's AI SDK makes the integration straightforward, and we've done it on systems we built and on ones we didn't.

Is our data used to train the model?

No. We use providers under API terms that exclude training, or self-hosted models where that's the better fit, and everything runs in an environment you control. Only the schema and the rows needed for an answer are processed.

What about the reports we already have?

They stay. This is for the long tail of one-off questions and the standing reports that used to be a developer task. Complex, high-stakes reports still get built properly, and the chat often tells you which ones are worth building.

What would you ask first?

Tell us the question and the system that holds the answer. One of our digital strategists will show you what it looks like on your own data.

Get in touch Back to AI for business