Book a readiness check
A daily operational brief, from your own systems

Five things worth knowing this morning. Including the one I got wrong.

Every weekday, a short brief assembled from your own data — what changed, what's drifting, what needs a person today. Each item shows the evidence behind it. And it publishes its own hit rate, because an advisor that never admits a miss isn't an advisor.

It does not give you business strategy. It tells you facts about your own operation that you would have found eventually, sooner and with the working shown. Everything else on this page follows from that limit.

Tuesday brief Northgate Supply · 06:40 local Sample company · not live data

Quiet week so far, with one exception. Nothing in cash or fulfilment needs you today. The billing thread below does, and it's been building since Thursday.

Needs a person today Owner: Priya N.

Billing complaints are up 4.6× and all trace to one invoice batch

Since Thursday, 218 billing tickets against a baseline of 47. Every one references an invoice from the 14 Sept batch. Same wording in 190 of them: customers charged for a plan tier they say they didn't select. No other ticket category is unusual.

Suggested: pull the 14 Sept batch and check the tier assignment before more invoices go out on the 28th. I can't tell you whether the batch is wrong — only that 190 customers describe the same thing.
Evidence
Helpdesk — 218 tickets, 5 days Billing system — batch 14 Sept #cust-ops — 11 threads
Confidence0.94
AssignSnoozeNot useful
Worth watching Owner: Marcus T.

Three of your ten largest accounts have gone quiet

No inbound contact from Halloway, Fenn Group or Ardent in 41, 38 and 36 days respectively. Their normal interval is 9–14 days. All three renew in Q1. Two had support tickets closed as resolved in the last quiet window.

Suggested: a check-in call before the renewal conversation starts. Silence isn't churn — it's just not information, and these three are worth having information about.
Evidence
CRM — contact history Helpdesk — closed tickets Renewal calendar
Confidence0.71
AssignSnoozeNot useful
Working

Warehouse pick times held through the volume increase

Order volume up 23% against last month; average pick time unchanged at 7.2 minutes. The September layout change looks like it absorbed the growth. First month it's been tested at this volume.

Suggested: nothing. Included because someone made a decision in September and it worked, and that usually goes unremarked.
Evidence
WMS — pick time logs Order volume, 60 days
Confidence0.89
AcknowledgeNot useful
I was wrong

Last Wednesday I flagged a supplier delay risk. It didn't happen.

I flagged Kestrel Components as a delivery risk based on three late shipments in a row. All subsequent deliveries were on time. Looking again, the three late ones shared a single cause — a public holiday in their region — which I treated as a trend rather than a one-off.

Adjusted: regional holiday calendars now excluded from delay-pattern detection. This one cost your ops lead about twenty minutes of unnecessary chasing, and it's on the scorecard below.
Evidence
Delivery records — 11 shipments Regional holiday calendar
Was0.66
Noted
Can't answer

You asked whether to raise prices in the Nordics. I'm not going to tell you.

That's a strategy decision requiring competitive positioning, customer willingness to pay and appetite for risk — none of which is in your systems. What I can put in front of you: Nordic gross margin is 4.1 points below your average, and three of the last five Nordic deals closed at a discount above 20%.

Suggested: those two facts are the input to your decision, not the decision. Anything that told you to raise prices from this data alone would be guessing in a confident voice.
Evidence
Margin by region — definition layer CRM — 5 Nordic deals
On the facts0.92
Noted

Five items, two of which are not advice. One admits a mistake, one refuses the question asked. A brief where every item is a confident recommendation is a brief nobody should trust by the third week.

The scorecard

It grades itself, monthly, and you see the grade

Every flagged item is checked afterwards against what actually happened. Not by me — automatically, against the outcome in your own systems, with the ones nobody acted on marked as unknown rather than quietly dropped.

94

Items raised in the last 90 days

71%

Confirmed useful by the owner who acted on them

9

Wrong, retracted and explained

17

Never acted on — outcome unknown, counted as neither

Kestrel Components — false delivery risk18 Sep

Cause: a regional holiday read as a supplier trend. Detection now excludes holiday calendars. Cost: roughly twenty minutes of chasing.

Flagged a churn risk that was a billing address change2 Sep

Cause: account activity dropped because the account was being migrated internally, which looks identical to disengagement from the outside. Now cross-checked against account-change records.

Missed a stock issue entirely for four days21 Aug

Cause: the warehouse feed had been failing silently since the 17th and nothing checked that the source was alive. The worst kind of miss — no signal at all rather than a wrong one. Feed health monitoring added.

A 71% useful rate is not a marketing number. It's what an honest brief looks like — and if a vendor shows you 98%, ask what they counted.

Design limits

What it refuses to do, on purpose

This category is full of products that promise a machine will run your business. The limits below are what separate a useful brief from an expensive horoscope.

01

No strategy advice

Pricing, hiring, market entry, whether to fire someone. These need context that isn't in any system, and a confident answer from data alone is worse than silence because it sounds researched.

02

No causation claims

It reports that billing tickets rose 4.6× and that they reference one batch. It won't tell you the batch caused it — that's a human checking a hypothesis, and the difference matters enormously.

03

Nothing acts by itself

No emails sent, no records changed, no refunds issued. It observes and suggests; a named person decides. Automation is a separate conversation with a separate risk profile.

04

Silence when there's nothing

A quiet week produces a short brief, sometimes two items. Manufacturing five insights a day to justify a subscription is exactly how these tools train people to stop reading them.

05

Never about individuals

It watches processes and accounts, never people's performance. The moment it becomes a surveillance tool, the humans feeding it start behaving differently and the data stops being true.

06

It says when it can't see

A dead data feed produces a visible gap, not a quieter brief. The August miss on the scorecard is exactly this failure, which is why feed health is now monitored as carefully as the data itself.


Prerequisites

This is the last thing to build, not the first

A daily brief is only as good as the definitions underneath it. If nobody agrees what "active account" means, the brief will be confidently wrong every morning — which is worse than no brief.

Agreed definitions for your core metrics

What counts as an active customer, a late delivery, a churn risk, a resolved ticket. Written down once, owned by someone. Without this the brief is generating opinions, not observations.

At least three connected systems with real history

Twelve months minimum. Patterns need a baseline, and "unusual" is meaningless until you know what usual looked like across a full seasonal cycle.

Named owners for the areas it watches

Every item needs somebody it belongs to. A brief that arrives to everybody arrives to nobody, and that's the most common way these die in month two.

Someone who will mark items useful or not

Thirty seconds a day. Without that feedback there's no scorecard, no tuning, and within a month it's noise that everyone archives unread.

If you're missing the first one, start there instead — a definition layer is worth building on its own, and it makes this cheaper and better later. I'd rather sell you that first and this second.


How we'd work

Read-only for a month before anyone gets a brief

The first month exists to find out what this system would have said about things that already happened — which is the only honest way to know whether it's worth reading.

Weeks 1–3

Readiness and definitions

Which systems, what history exists, and what your core terms actually mean. Sometimes this ends with "build the definition layer first" — and I'll say so.

Weeks 4–7

Backtest in silence

Run it over the last six months and see what it would have flagged. You judge those against what really happened, before anyone receives a live brief.

Weeks 8–10

One team, live

The brief goes to a handful of named owners. Feedback tunes the thresholds — mostly downward, because the first version always flags too much.

Weeks 11–12

Scorecard and handover

Self-grading turned on, runbook written, and your team trained to add new checks without me.


Pricing

Published, and the first step can end in "not yet"

Start here Readiness check

Do you have the data, definitions and owners for this to work?

$5,000

Two weeks · credited against a build

  • Inventory of systems and usable history
  • Which checks are actually possible today
  • Definition gaps that would break it
  • A straight yes, not yet, or no
  • Yours to act on without me
Book a readiness check
Build

Backtested, tuned, and live to one team with the scorecard on.

$30k – $55k

10–12 weeks · check credited

  • Six-month backtest you review before launch
  • Daily brief in Slack, Teams or email
  • Evidence and confidence on every item
  • Self-scoring with monthly report
  • Feed health monitoring built in
Discuss a build
Ongoing

New checks, tuned thresholds, and someone watching the watcher.

from $5,200/mo

Cancel any month · 30 days notice

  • New checks as the business changes
  • Monthly scorecard review with you
  • Threshold tuning from real feedback
  • New systems connected as you adopt them
  • Designed so your team takes it over
Talk about ongoing

The one number that decides whether to keep paying

After ninety days live, we look at the useful rate — the proportion of items the owner marked as worth their attention. If it's below 50%, the brief is noise and you should stop. I'll say that out loud rather than let a subscription drift.

Everything is built to make that number honest: items nobody acted on are counted as unknown rather than as successes, and every retraction stays on the scorecard permanently.

Model and infrastructure costs sit in your own accounts, typically $120–$450 a month. Not marked up.


Questions

The sceptical ones, which are the right ones

How can it possibly know enough about my business to advise me?

It can't, and it doesn't try. It knows what's in your systems and what normal looks like there. That's enough to notice that billing tickets are 4.6× baseline and all reference one invoice batch — which is a fact, not advice.

Everything requiring judgement about your market, your people or your strategy is explicitly out of scope, and the brief says so when you ask. The fifth card in the sample is that refusal.

How is this different from alerts and dashboards we already have?

Threshold alerts fire when one number crosses a line, which produces either noise or silence and rarely the thing you needed. Dashboards require you to go and look, and to already suspect what you're looking for.

The difference here is combination and context: patterns across several systems, compared to your own history, ranked by whether a person needs to act today, and delivered without you asking. The honest overlap is real though — if your existing alerting is good and people trust it, this is a smaller improvement than the price suggests.

Won't people just start ignoring it?

That's the default outcome for this whole product category, and the design fights it in three specific ways: it stays silent when there's nothing worth saying, every item has one named owner rather than going to a distribution list, and the useful rate is measured so decay is visible before it's terminal.

If the useful rate drops below 50% at ninety days, the honest answer is to stop. That's in the pricing section for a reason.

What stops it telling us something confidently wrong?

Every item shows its evidence and a confidence score, and low-confidence items are framed as questions rather than findings. It reports what changed, not why — no causation claims, because that's where these systems usually embarrass themselves.

Then the scorecard: wrong items are retracted publicly, with the cause explained and the detection adjusted. Three of those are on this page. A tool that hides its misses is a tool you'll eventually stop believing all at once.

Is this watching our staff?

No, and I won't build the version that does. It watches processes, accounts and volumes — never individual performance, never who said what. If leadership's actual goal is monitoring people, this is the wrong project and I'd decline it.

Practical reason as much as an ethical one: the moment people believe they're being watched through it, the data feeding it stops reflecting reality.

What if our data isn't good enough?

Then the readiness check says so in two weeks, and you've spent $5,000 instead of $40,000. It happens often — usually missing definitions, or not enough history for a baseline.

In that case the definition layer is the thing to build first, and it's useful on its own regardless of whether you ever come back to this.


Who builds it

I've spent eight years on alerting that had to be worth reading at 3 a.m.

I'm Bahman Shadmehr. Automated trading platforms on the Texas wholesale power market and US equities, a national payment gateway I helped decompose while live, and the monitoring underneath all of it.

Those systems taught the lesson this product is built on: an alert that fires too often is worse than no alert, because people learn to dismiss it and then miss the real one. Tuning thresholds so a page means something, and measuring whether it did, is most of what that work actually was.

A daily brief is the same discipline aimed at a business instead of a pipeline. That's why the scorecard exists, and why the limits section is longer than the features.

2024 — 2025Automated energy trading, ERCOT — health metrics and anomaly alerting across the pipeline
2023 — 2024US equities trading platform — anomaly detection on daily trading jobs
2022 — 2023Vgang — Kubernetes platform, integration microservices
2020 — 2021Zibal — payment gateway, Prometheus and Grafana monitoring
2017 — 2020Rahpa — async backends, real-time tracking and dashboards

Python, Go, Kubernetes, AWS, GCP, Postgres, InfluxDB, Prometheus, Grafana. Remote, UTC+3. 76 technical posts · LinkedIn

Next step

Tell me the last thing you found out too late

Not a hypothetical — an actual one from this year. I'll tell you within a day whether a brief like this would have caught it, and I'll tell you when it wouldn't have.

info@bshadmehr.me

Two clients at a time Reply within a day Remote · UTC+3

Useful in a first message

  1. The systems you run day to day.
  2. Roughly how much history is in them.
  3. Who'd receive the brief, by name or role.
  4. Whether your core metrics are defined anywhere.
  5. The last thing you wish you'd known sooner.