The TWIMCO notebook
Field notes.
Useful observations from inside the work.
For people building a better way.
Operations · 38 notes

Opening note / Operations
Photo proof before the carrier claim—and before you reship
The customer sends a blurry kitchen photo. Someone refunds and reships the same day. The carrier claim dies later for lack of evidence you could have asked for on hour one.
Read the note ↗︎
Paying online does not mean the desk visit goes away
The fee cleared online. The email said approved. The resident still stood in line because the stamp, badge, or wet signature never moved online with the payment.
Read the note ↗︎
Decide what still works when you switch it all off.
When a retailer takes systems offline on purpose to contain a security problem, stores can still ring up sales — if payment, prices, promised orders, and a customer notice were designed to run alone. Write that list tonight.
Read the note ↗︎
Pharmacies check the bottle against the order. Your packing bench can too.
A customer orders the blue one in medium and gets the green one in large. It's a small slip with a long tail of refunds, return labels and reshipping. Pharmacies, where a wrong item matters far more, built their work around a habit worth borrowing.
Read the note ↗︎A records request passes through five people. Only one of them is the clerk.
Someone asks the city for a set of emails and inspection reports. Behind that one request sit a clerk, a couple of departments, a lawyer, a deadline in law and, very often, a shared inbox holding the whole thing together.
Read the note ↗︎
Before you replace the dispatch whiteboard, write down everything it does.
Magnets for technicians, columns for the day, a red marker for anything urgent. It looks old-fashioned, and the plan is to replace it with scheduling software. Spend a week noticing what that board quietly does first, or the new system will drop it.
Read the note ↗︎
Let people wait for the counter somewhere other than the lobby.
At eight in the morning the lobby fills, everyone takes a paper ticket, and nobody dares leave in case their number is called. It doesn't have to work like that. Five principles for letting people wait somewhere better, without losing anyone who doesn't carry a smartphone.
Read the note ↗︎
Rebuild somewhere else once, before you have to.
A Japanese cloud provider just told hundreds of customers their data probably can't be recovered, and that the only way back is a backup they kept themselves. Do you have one? Has anyone ever rebuilt from it?
Read the note ↗︎
When someone leaves, the risk is in the accounts nobody listed.
Disabling a departing colleague's email takes a minute. Finding the vendor portal they logged into, the report that runs under their name and the subscription they paid for on expenses takes much longer, and it usually happens after something stops working.
Read the note ↗︎
Automate the invoice reminder. Keep the phone call.
Nobody enjoys chasing a client for money, so it slides until the end of the month. Reminders are a great job for software, as long as the software knows when to stop: the invoice is disputed, the customer already promised a date, or the payment arrived this morning.
Read the note ↗︎
Before the second warehouse opens, decide which orders it gets.
A second warehouse sounds like faster shipping. In the first week it mostly produces questions: who gets this order, what happens when half of it is in each building, and which stock count the store should believe.
Read the note ↗︎
Your approval chain will stall on someone's vacation. Plan for it now.
Picture the last week of the quarter. A purchase is stuck, the approver is somewhere sunny, and three people keep refreshing their inboxes. Almost all of it can be fixed before it ever happens.
Read the note ↗︎
Freeze config the night before you cut over.
On the evening before cutover, someone flips a flag "just for the test" and a cron job deploys an old config. By morning, what you cut over isn't what you reviewed. A freeze needs a list you can check, not a channel message asking people to be careful.
Read the note ↗︎
Replay a dead letter, or leave it named.
A webhook fails halfway, and by morning there's a folder of payloads nobody is clearly allowed to resend. Run the handler again and you might charge, notify or advance a deal twice. A failed delivery should stay a record with an owner.
Read the note ↗︎
Decide the delete path before you store the record.
A workflow stores a row because it needs a fact on Tuesday. Two years later it's in a warehouse, an export and a ticket attachment, and nobody knows who may remove it or what breaks if they do. Decide how a record ends before you first save it.
Read the note ↗︎
Name what you will shed before the spike.
Auction night, a campaign send, a go-live Monday. You know when the spike comes. Unless it's written down, you don't know which work is allowed to wait, and the spike will drop something you meant to protect.
Read the note ↗︎
Most "where is my application?" calls are a status problem.
If people keep calling to ask where their application is, more phone staff won't fix it. They need to see what state it's in, what happens next, and whether anything is waiting on them.
Read the note ↗︎
Before you automate the Friday report, find out who reads it.
Someone exports a file every Friday and spends the morning cleaning it up. Before you automate that, ask who opens it and what they do differently because of it.
Read the note ↗︎
Your spreadsheet is already software. Treat it like it.
There's a tab called FINAL v3 that three people edit and one person really understands. That isn't a messy file. It's an application nobody has designed yet.
Read the note ↗︎
Rotate credentials like a cutover, not a chore.
A calendar ping is not a rotation plan. Keep both values valid for a named window, flip callers in order with probes, and name who rolls back if the new one fails.
Read the note ↗︎A familiar problem? Let’s look closer.
Tell us where you want to go. We’ll find the first thing worth changing.
Tell us about it ↗︎