Reviews
Part of Business intelligence explained for 2027
Business intelligence examples: patterns worth studying
Business intelligence patterns worth studying: nine recurring artifacts that quietly became load-bearing, what each reveals, and how to find your own.
Intelligence work repeats itself across companies that have nothing else in common. The same handful of situations turn up, wearing different names, and each one is a signal about something structural that has not been built yet.
What follows are nine of those recurring shapes. None is a company and none is a story with an ending. They are patterns you can recognize on your own team this week, with a note on what each one is really telling you.
What to take away
- These shapes are diagnostics. Each one names a missing piece of the model, not a badly behaved person.
- The work people do after they get a number is the most reliable list of what to build next.
- Recognizing the pattern is most of the fix, because it converts an annoyance into a specific piece of work.
1. The reconciliation report that became the source of truth
Two systems disagree, so somebody builds a report that compares them line by line to find the gap. Within a year, people stop using either original system and quote the reconciliation instead, because it is the only place the difference is visible.
What it tells you: the reconciliation encodes the mapping between two models, and that mapping exists nowhere else. Reconciling systems that each hold their own version of the same entity is the problem master data management exists to address. It belongs in the modeled layer as a documented relationship, not in a report whose original purpose was temporary.
2. The export that is really a join
Someone pulls a report to a spreadsheet every week and immediately pastes a second list beside it. Nobody calls this an integration problem, because each half works fine.
What it tells you: two entities in your business are related and your model does not know it. The paste is a join being performed by hand, and it is being performed slightly differently by each person who does it.
3. The alert that should have replaced a dashboard
A page exists that one person checks several times a day, looking for a specific condition. They describe it as monitoring. They also miss it sometimes, usually on the days it matters.
What it tells you: the requirement was never a page. It was a condition and a recipient. Anything a human is checking on a schedule to see whether a threshold was crossed is an alert that has not been written yet.
4. The metric that is a queue in disguise
A team reports an average age, an average wait, or an average time to resolve, and the number stays comfortably flat while complaints rise.
What it tells you: the population is a queue, and averages over queues hide the tail that everyone actually experiences. The interesting object is the distribution and the oldest item in it. Report the count of things older than a stated threshold and the average becomes redundant.
5. The report nobody reads and nobody will cancel
A recurring report goes out. Open rates are low, nobody references it, and every attempt to retire it meets vague resistance.
What it tells you: the report is doing a non informational job, usually reassurance that something is being watched. Naming that out loud is more productive than arguing about usage numbers. Offer to replace it with an exception notice that only arrives when something is off, which provides the same reassurance at a fraction of the cost.
6. The spreadsheet that encodes a business rule
One person maintains a file that everyone depends on. It applies an allocation, a mapping, a correction, or a hierarchy that exists in no system.
What it tells you: there is a real business rule with no owner and no written definition. The rule is the asset, not the file, and it belongs in a data dictionary that outlives whoever maintains the spreadsheet. Extract it, write it down, get someone to confirm it is still correct, and put it in the modeled layer. The spreadsheet then retires itself without an argument.
7. The number that only exists in a meeting
A figure is quoted regularly, everyone accepts it, and no system produces it. Someone calculates it privately before each meeting.
What it tells you: the organization has a metric it genuinely cares about and has never asked for. It is often the single highest value thing to build, precisely because demand has already been demonstrated for months.
8. The one off that became a monthly obligation
An analysis was done once, someone liked it, and it is now expected every month. It was never designed to be repeatable, so each run is a partial rebuild.
What it tells you: the boundary between analysis and reporting was crossed without anybody deciding to cross it. Either commit to it properly, with a definition, a model, and tests, or stop it. The middle state consumes the most time and produces the least trust.
9. The hand maintained lookup table
Region assignments, account tiers, product groupings, a mapping of teams to owners. Someone updates it manually, and it is always a little out of date.
What it tells you: a dimension is missing from your data model. The manual list is the specification for it. The update process, whoever remembers to change it and when, is the part that needs designing, not the table itself.
Reading these as a set
| Pattern | The missing thing |
|---|---|
| Reconciliation as truth | A documented mapping between two models |
| Export then paste | A modeled relationship between two entities |
| Human checking a threshold | An alert with a named recipient |
| Average over a queue | A distribution and a stated threshold |
| Unreadable but uncancellable report | An exception notice |
| Load bearing spreadsheet | A written, owned business rule |
| Meeting only number | A metric nobody thought to request |
| One off gone monthly | A decision about reporting versus analysis |
| Manual lookup | A dimension and a maintenance process |
Every row in that right hand column is a small, specific piece of work. That is the value of pattern matching: it turns a vague sense that things are inefficient into a list you can sequence.
How to find yours
Spend one week writing down what people do in the ten minutes after they receive a number. Not what they asked for, what they do next. Copy, paste, filter, phone someone, adjust, forward. Each of those actions is a requirement your system has not met, and the list will be short enough to act on.
Related reading on this site
The economics behind why these shapes recur are set out in business intelligence. For the organizational moves that create several of them, see nine mistakes made around a data team. Patterns three and five are delivery choices covered in dashboard design and recurring reporting. For where the fixes sit relative to each other, see the layers a project passes through.
Common questions
Several of these describe things my team does. Is that bad?
No. Every one of them started as somebody solving a real problem with what they had. The pattern is only a problem when it stays informal long enough to become load bearing.
Which is the most urgent to fix?
The load bearing spreadsheet, because it has a single point of failure who takes holidays. The meeting only number is the highest value to build, because demand is already proven.
How do I raise this without it sounding like criticism?
Describe the pattern, not the person. "We are doing this join by hand every week" is a statement about the model. "You keep exporting to a spreadsheet" is a statement about someone's work.
Do these ever go away on their own?
The manual ones get harder as the company grows, so they surface eventually. Waiting for that means they surface as an incident rather than as a plan.
