Using AI to Prepare Your Morning Business Briefing
Last updated:
The half hour every owner loses
Most owners of small and mid-sized businesses start the day the same way. Check the bank. Open the sales dashboard. Scan the inbox for anything alarming. Look at the jobs board. Glance at Slack or Teams for overnight problems. By the time the picture is assembled, 30 minutes have gone and the day has already started without you.
A morning briefing does that assembly for you. Done properly, it is one of the most satisfying small AI projects a business can commission, because the owner uses it every single day and notices immediately when it is wrong.
What a good daily briefing contains
Resist the urge to include everything. A briefing that runs to three pages is a report, and nobody reads reports at 7:30.
- Three to five headline numbers compared with a sensible baseline: yesterday's sales against the same weekday last month, cash position, jobs completed against planned.
- What changed. Two or three sentences on anything outside its normal range.
- Decisions needed today. An overdue approval, a large customer threatening to leave, a supplier price rise.
- Things to be aware of. A key person off sick, a delivery delayed, a review posted overnight.
- Links to the source. Every item should be one click from the system it came from.
If a section is empty, the briefing should say so in one line. 'No overdue approvals' is useful information.
The architecture that stops it inventing things
The mistake we see most often is handing a language model access to everything and asking it to 'summarise the business'. It will. It will also occasionally produce a revenue figure that looks right and is not, and a briefing you cannot trust is worse than no briefing.
The design that works separates the jobs cleanly:
| Step | Done by | Why |
|---|---|---|
| Fetch figures from Xero, Shopify, CRM, job system | Plain code via APIs | Exact and repeatable |
| Calculate changes against baseline | Plain code | Models are poor at arithmetic |
| Flag anything outside thresholds | Plain code with rules you set | You decide what counts as unusual |
| Read unstructured sources (inbox, reviews, chat) | Language model | This is what it is good at |
| Write the short narrative | Language model, given only the computed facts | Readable, and cannot drift from the data |
The model is the writer, not the analyst. Give it the facts and ask it to explain them.
This is the same principle that runs through our work on AI in reporting and dashboards: computation stays deterministic, language stays with the model.
Where the data usually comes from
For a typical 20 to 50 person business, a briefing draws on four to six sources. The accounting system provides cash and overdue invoices. The sales or ecommerce platform provides orders. A CRM or job management tool provides pipeline and operational status. The shared inbox and review sites provide the unstructured signals that numbers miss.
Connecting those is usually the bulk of the work. Most modern tools have reasonable APIs; older on-premise systems may need a nightly export. It is worth checking early, because a briefing that cannot see the one system that matters most is not worth building.
Delivery: email, Teams or a page
Send it where the owner already looks first. For most people that is email. For teams living in Microsoft Teams or Slack, a message in a private channel works well and lets two or three managers see the same thing.
- Plain text or very simple formatting, readable on a phone
- The same structure every day so the eye knows where to go
- A timestamp showing when the data was pulled
- A clear note when a source failed, rather than silently missing data
That last point catches people out. If the Xero connection fails overnight and the briefing simply omits cash, the owner assumes nothing changed. Failures must be loud.
What it costs and when it is not worth it
A simple briefing from two or three well-documented systems is a small project, often a couple of weeks of build. Running costs are low because it runs once a day over a modest amount of text. The ongoing cost is maintenance: APIs change, a new system is adopted, thresholds need adjusting.
It is not worth building if your business genuinely fits on one dashboard you already check, or if the figures you care about are in spreadsheets updated by hand at unpredictable times. In the second case, fix the data first. We would rather tell you that than build a briefing that reports stale numbers with great confidence.
How we approach a briefing project
At SpiderHunts we start by sitting with whoever reads it and writing down exactly what they check every morning, in what order, and what makes them pick up the phone. That list becomes the specification. We build the data pulls and thresholds first, run the briefing without the AI narrative for a week, then add the written summary once the numbers are trusted.
If this sounds like your morning, our automation service covers exactly this kind of integration, and a briefing is often the first piece of a wider tidy-up of how information moves around the business.
Frequently asked questions
Can ChatGPT or Copilot write my morning briefing without a custom build?
How do I stop an AI briefing reporting wrong numbers?
What time should the briefing run?
Can a briefing cover several managers with different priorities?
Tired of opening six tabs before you can start your day?
Tell us which systems hold the numbers you check every morning. We will sketch what a briefing would look like and whether it is worth building for your size of business.