# Make your business report to you Stop holding it in your head. Sort every event by how much it matters and how soon you must act. 2026-10-20 When I was younger, I kept forgetting things and leaving them half done. My dad called me a "lebrão" — a big hare, after the one in Aesop's fable: so sure of his speed that he napped, and lost to a tortoise. \[1] I started the most absurd and diverse projects, and quit long before the finish line. Years later, I learned it was ADHD and was better able to manage it; but the road there taught me a lot regardless. > \[!ASIDE handwritten] > Yes, I typed that em-dash myself. They are useful punctuation marks and I hate that AI made people mad about them! That problem pushed me to study methods and systems, because I couldn't trust my own memory or willpower. What I found out, however, is that you don't need ADHD to hit the same wall. None of us can hold everything we need in our heads. And a business holds far more than any one head can, as I learned the hard way. ![The hare naps under a tree while the tortoise walks on toward the finish line. Illustration made with ChatGPT (gpt-image-2.5-flare).](https://tn0oilsmy7aw0f5x.public.blob.vercel-storage.com/posts/one-morning-message/hare.png) My latest system helps my cofounder and me with exactly this. At **[Desio](https://desio.app)**, the hospitality platform we build, we keep an eye on many things at once: payments, subscriptions, merchant accounts, AI costs, background jobs. We also believe we must own our processes before we hand them to anyone. An Excel spreadsheet wouldn't work as the brains of this whole operation for us. Filled in by hand, it can't hold every event as it actually happens. It only knows what someone remembers to type into it. ## Creating your personal system You run an operation. Maybe it's a small business, maybe a team inside a big company. You know what goes on because you keep it in your head, and you open the dashboards when you need a number. When something important happens, someone tells you. That works until it doesn't. Your head drops things without a sound. The dashboard answers only when you remember to look. And the event that nobody owns, good or bad, reaches you late or never. So how do you know what happened in your business without holding it in your head? You stop holding it. You make the business report to you: every relevant event gets tracked, measured, and sent to a single place, to then get sorted by how much it matters and how soon you must act. > Your mind is for having ideas, not for holding them. > > — **David Allen** \[2] Now think of what a business asks your head to hold. Sales, payments, customers, the team, the code. I think the answer is not more discipline. It's a system outside your head that holds the list for you. Here is a **step by step process** of how this system works, and how you can build your own. To start, all you need is one of many AI assistants in the market today (ChatGPT, Claude, Gemini, etc.), connected to the tools where your business happens, and one table. The prompts are plain text, so you can paste them into any of them. Where they differ, mostly in scheduling, the last step says how. For the events that can't wait, you'll also want an automation tool such as n8n. I know the objection, because I used to make it: "If I check the dashboard, I'll know." Only if you remember to look. And a dashboard shows the things that someone chose in advance. When something unexpected happens, you may not even know where to look. A dashboard is pull: it needs your memory. A report is push: it comes to you. ## Step 1: list what actually happens Many teams already track tasks. A task board holds what you plan to do. What I want is the other list: what actually happens. A sale. A failed payment. A new customer's first order. An error in the night. It helps to separate three layers: what someone sees, what things could do, and what actually happens. \[3] ![The tortoise works down one short checklist while the hare drowns in sticky notes, boards, apps and calendars. Illustration made with ChatGPT (gpt-image-2.5-flare).](https://tn0oilsmy7aw0f5x.public.blob.vercel-storage.com/posts/one-morning-message/task-apps.png) What someone sees is the easy one. It's what a dashboard shows: the things someone chose to track, over the time window you picked. What things could do sits beneath both. It's the powers a system has because of how its parts are arranged: the bug nobody has hit yet, the edge case in a payment flow. A power can sit unused for months, until the day it fires. You can't list every one in advance, but it exists all the same. What actually happens is where a system can work. It's what happens, whether anyone sees it or not. Some of it could be measured and simply isn't. The system's job is to make it seen. So our list at [Desio](https://desio.app) is a list of what actually happens, whether we look or not. It covers both sides of the company. On the business side: payments, subscriptions, refunds, merchant accounts, loyalty. On the dev side: AI cost, background jobs, webhooks, feature flags, health checks. None of these waits for someone to open a dashboard. Each one gets reported to the system, and the next step decides when and how we hear about it. Good events count too. When a new merchant gets its first outside visit, that's an event, so somebody follows it up. > \[!NOTE] > > **Do it yourself: your event list** > > Connect your tools to your assistant, then go through them together. Ask for events, not tasks: > > ```prompt > Go through [your tools]. List every kind of event that happens in my business: sales, payments, customers, the team, the systems. For each one, tell me where it shows up, roughly how often, and whether anyone tracks it today. > ``` > > Then push past the dashboard. Ask what happens that nobody measures yet. That's the part of what actually happens that a dashboard never shows you. The AI proposes; you decide what stays on the list. ## Step 2: mark how much each event matters, and how soon Here's the catch. Send every event the moment it happens, and you'll stop reading them. I see this every day with AI coding tools. A tool that asks me to confirm every step teaches me to click yes without reading. Google's SRE book says the same about alerts: "I can only react with a sense of urgency a few times a day before I become fatigued." \[4] The fix is an old idea. In 1954, Eisenhower quoted a former college president: "I have two kinds of problems, the urgent and the important." \[5] Importance and urgency are two different questions. Importance decides how loud an event is. Urgency decides when you hear about it. An event that is neither doesn't get sent at all. It goes to a log. ![Importance sets how loud, urgency sets when: four quadrants, from "loud, now" to "neither", which goes to a log.](https://ricardokrug.com.br/en/blog/one-morning-message/figures/quadrants.png) Desio marks every event on both axes. On October 14, 2026, it had 94 types of event. The level decides when the system handles each type: 32 at once, 55 in a batch every 30 minutes, 7 the next morning. Those are types, not messages: we don't get 55 notifications every half hour. A batch carries only the events that are still waiting, and an empty batch sends nothing. No level mute can silence the first group. ![The 94 event types by importance and urgency. On the diagonal, the two agree; the 22 off it are the ones a single scale gets wrong.](https://ricardokrug.com.br/en/blog/one-morning-message/figures/matrix.png) The interesting part is the 22 off the diagonal. A critical event that can wait half an hour. A minor one that can't. If you sort on one axis only, you get those wrong. So how do you know which level is right? You start by understanding the event: what it is, what it represents, and how it connects to the rest of the business. Take a refund. On a dashboard, it's just another number. But one refund touches at least four parts of the business. The customer: often something went wrong for them, and how we answer shapes whether they come back. The merchant: it's their revenue, and a run of refunds may point to a problem at their venue. Our cash: money leaves, and the processor's fees may not come back with it. And the dev side: our systems have to process the refund, and that step can fail on its own. ![One refund touches four parts of the business: the customer, the merchant, our cash, and the dev side.](https://ricardokrug.com.br/en/blog/one-morning-message/figures/refund.png) Each link is a reason the refund might matter, and a different person who might need to hear about it. Together, they set its level. You need to know what something is, and what it relates to, before counting it tells you anything. Understanding comes first. \[6] Then you measure: we record each new event and watch what it does to our day-to-day. Some levels are obvious from day one: a customer complaining about a money transaction is top priority. Others aren't. Some fraud checks need a baseline: you can tell usual behaviour from unusual only once you know what usual looks like. > \[!NOTE] > > **Do it yourself: your levels** > > Ask it to place every event on both axes, with a reason you can check: > > ```prompt > For each event on the list, propose an importance (critical, high, low) and an urgency (now, within 30 minutes, next morning, log only). Give one line of reasoning for each. Then list the events that are important but can wait, and the ones that are minor but can't. > ``` > > Read that last list yourself. Those off-diagonal events are where a one-axis system goes wrong. > > Some levels are obvious. For the rest, map what the event touches, the way the refund diagram does above: > > ```prompt > Take [event]. What does it represent? Which customers, partners, money and systems does it touch? What would make one occurrence more serious than another? > ``` > > In practice, log the events for a few weeks, and ask the AI to compare what actually happened with the level you gave each one. Some levels will move. ## Step 3: one place decides How does each tool know which level to use? It doesn't. At Desio, the code that reports an event says what happened, and nothing more. One registry decides the level, the label, the severity, and the wording. ![Code says what happened; the registry decides the rest. A high-value refund's row sends it to the 30-minute batch.](https://ricardokrug.com.br/en/blog/one-morning-message/figures/registry.png) A high-value refund goes out in the next 30-minute batch because its row says so. The payment code never decided that. That sounds like a detail. I think it's the part that keeps the system alive. When an event turns out louder or quieter than you thought, you move it in one line, and every tool follows. > \[!NOTE] > > **Do it yourself: your registry** > > Put the decisions in one file, one entry per event: a spreadsheet works, and so does a JSON file like this one. Every prompt and every automation reads from it. Don't let the JSON format intimidate you: it's only labels and values, and your assistant can write it and read it for you. > > ```prompt registry.json > { > "events": [ > { > "event": "refund_issued", > "importance": "high", > "urgency": "within_30_minutes", > "who_hears_it": ["finance", "support"], > "wording": "Refund of {amount} for {customer}" > }, > { > "event": "payment_failed", > "importance": "critical", > "urgency": "now", > "who_hears_it": ["founders"], > "wording": "Payment of {amount} failed for {customer}" > }, > { > "event": "first_outside_visit", > "importance": "low", > "urgency": "next_morning", > "who_hears_it": ["customer_success"], > "wording": "{merchant} got its first visit" > }, > { > "event": "job_retried", > "importance": "low", > "urgency": "log_only", > "who_hears_it": [], > "wording": "{job} retried {count} times" > } > ] > } > ``` So, we begin by understanding what are the components of our business system and listing the events that actually happen. We mark each one for how much it matters and how soon we must act. And one registry holds every decision, so every tool follows it. Now for the part we see each morning. ## Step 4: start the day from one brief The events that can wait until morning end up in one place: a brief at 09:00. Before it, nothing came to us. We had to go looking: open the dashboards, log into different accounts and services, and check one tool after another. Then we linked things up by hand. Whatever we didn't think to check, we didn't see. Now the morning's news comes in one brief, and what can't wait still comes on its own. It opens with yesterday's numbers, adds the weekly view on Mondays, then the events that waited, then a pulse per customer. The phone version stays short. When it runs out of room, it shortens each section first, then drops whole sections from the end. The email keeps every section. And an event that doesn't fit isn't lost: it waits for the next day's brief. ![The tortoise reads one morning brief over coffee while the hare sleeps beside a wastebasket of sticky notes. Illustration made with ChatGPT (gpt-image-2.5-flare).](https://tn0oilsmy7aw0f5x.public.blob.vercel-storage.com/posts/one-morning-message/morning-brief.png) > \[!NOTE] > > **Do it yourself: your morning brief** > > Create a scheduled task that runs every morning. As of October 2026, all three assistants can do it, each in its own way. \[7]\[8]\[9] > > ![How each assistant runs a scheduled task: where it lives, how often it runs, the plan it needs, and what to know.](https://ricardokrug.com.br/en/blog/one-morning-message/figures/assistants.png) > > A starting prompt that should work in any of them: > > ```prompt > Read the registry. Pull yesterday's events from [your connectors]. Write the morning brief: yesterday's numbers first, then the events that waited, then one line per customer. On Mondays, add the weekly view. Keep the phone version short: if it runs long, drop whole sections from the end. Anything that doesn't fit goes into tomorrow's brief. > ``` > > Run it by hand a few times before you trust the schedule, and tighten the prompt each time. Then add a second task, once a week, to review the list: > > ```prompt > Read this week's event log and the registry. Which events fired more often than their level suggests? Which never fired? What showed up that isn't on the list yet? > ``` > > It suggests; you decide. Then you change the rows in the registry, and every tool follows. > > A scheduled task runs at most once an hour, so it can't carry your "now" or 30-minute events. Those need an automation tool such as n8n: it receives each event from its source, looks up its row in the registry, and sends it right away or in the next 30-minute batch. I won't teach n8n here; I hope to cover it in a course one day. ## Be the tortoise The hare didn't lose because he was slow. He lost because he trusted his speed and took a nap. The tortoise trusted neither speed nor memory, and kept going, one step at a time. You don't need more discipline or a bigger dashboard to run a business. You need the business to report to you: every event on one list, each one marked for how much it matters and how soon you must act, and one brief each morning for everything that can wait. So start here, today. List the ten events in your business that you must never miss, and mark each one: how much it matters, and how soon you must act. That list is your first version, and every step above builds on it. And if you'd rather not build it alone, that's the work I do: I build systems like this one with teams, from a spec that stays yours. [See how an implementation works](/en/automation/implementation). ## References 1. Book: Aesop, "The Tortoise and the Hare," in *Aesop's Fables*, trans. Laura Gibbs, Oxford World's Classics (Oxford: Oxford University Press, 2002), fable 237 (Perry 226). 2. Book: David Allen, *Getting Things Done: The Art of Stress-Free Productivity*, rev. ed. (New York: Penguin Books, 2015), chap. 14, under "Distributed Cognition: The Value of an External Mind." 3. Book: Roy Bhaskar, *A Realist Theory of Science* (London: Routledge, 2008), 2, table 0.1. Bhaskar calls the three layers the empirical, the real, and the actual. The book first appeared in 1975. 4. Book: Rob Ewaschuk, "Monitoring Distributed Systems," in *Site Reliability Engineering: How Google Runs Production Systems*, ed. Betsy Beyer, Chris Jones, Jennifer Petoff, and Niall Richard Murphy (Sebastopol, CA: O'Reilly Media, 2016), chap. 6, [https://sre.google/sre-book/monitoring-distributed-systems/](https://sre.google/sre-book/monitoring-distributed-systems/). 5. Primary: Dwight D. Eisenhower, "Address at the Second Assembly of the World Council of Churches, Evanston, Illinois," August 19, 1954, The American Presidency Project, ed. Gerhard Peters and John T. Woolley, [https://www.presidency.ucsb.edu/documents/address-the-second-assembly-the-world-council-churches-evanston-illinois](https://www.presidency.ucsb.edu/documents/address-the-second-assembly-the-world-council-churches-evanston-illinois). 6. Book: Andrew Sayer, *Method in Social Science: A Realist Approach*, 2nd ed. (London: Routledge, 1992), 176. 7. Primary: "Schedule Recurring Tasks in Claude Cowork," Claude Help Center, Anthropic, accessed October 14, 2026, [https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork](https://support.claude.com/en/articles/13854387-schedule-recurring-tasks-in-claude-cowork). 8. Primary: "Scheduled Tasks in ChatGPT," OpenAI Help Center, OpenAI, accessed October 14, 2026, [https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt](https://help.openai.com/en/articles/10291617-scheduled-tasks-in-chatgpt). 9. Primary: "Create & Manage Schedules for Tasks in Gemini," Gemini Apps Help, Google, accessed October 14, 2026, [https://support.google.com/gemini/answer/17094710](https://support.google.com/gemini/answer/17094710). Google calls the feature schedules for tasks, on the Scheduled page. It is not available in the European Economic Area, Nigeria, Switzerland, or the United Kingdom.