Bring the day into view
Make a short briefing from current records, with evidence and decisions kept visible.
Bring the methods together
Use a shared work log, an inbox and current system reports. A useful briefing points back to those sources rather than becoming another copy of the facts.
The sequence
File new arrivals and record receipts before summarising them. Read open work, money records and the latest server and backup report . Write a short briefing, starting with blocked work and anything needing a person. Link each item to its evidence. Save the briefing in the usual place. Bring urgent exceptions to the channel people check.
Done when
Someone can see what needs attention and follow an item to its source. The briefing reports; it does not decide what to pay, send or fix. Scheduled delivery requires a configured runner and access to each source.
How we use it at Pitch
At Pitch, the board is our shared work log. An assistant is software that follows our instructions with access to agreed tools. A watcher checks for changes and reports them; a worker runs a configured routine. Those roles need explicit instructions, access and permissions. Context and boundaries The morning briefing is the workflow that tells us where everything stands before we have asked. The decisions it leaves with us are the ones that matter: what to work on, and what to do about anything that is stuck. Everything else, reading the board, the inbox, the server and the money, a worker does every morning on its own. The setup The board that every other workflow writes to, which is what makes a briefing possible at all. A scheduled task in the cloud that runs the worker every morning. Two channels, one for the briefing and one for alerts. And one design choice that keeps it useful: the worker reads, files and reports, but takes no action on what it finds, so anything that needs a decision arrives as a "needs you" item for us. Our sequence Every morning the worker starts on its own; no computer of ours needs to be on. It files the night's arrivals first: new files, new mail, new receipts . It reads the board, the latest server report and the money: what is owed and what has gone out. It writes the briefing as a row on the board and posts it to the team channel. Anything blocked, any failed charge and anything waiting on us goes to the alerts channel as well. The principle The briefing is written from the board, not from memory. If it happened, it's a row, and if it's a row, the briefing can see it. What stays with a person We still read it, and we still decide what to work on. Gathering it, and noticing what needs us, stopped being ours. What it took us The routine existed first as something we ran by hand at the start of a session, then as a version on one of our own machines that emailed the briefing. In September it moved to a scheduled task in the cloud and began writing to the board and the team channel instead. How the process began Each morning we'd open the plan, the client list and the list of open work. Check what had changed in the code overnight and what was waiting for review. Read the inbox and the calendar. Look at the server and the money. Write ourselves a list, and decide what to work on.