One live Claude
Claude will draft all ten before you send one
One live ticket per session this week, then a Friday count of every extra chat
Claude will keep writing for as long as you keep opening chats. That is what the product does. Paste a ticket and it drafts a reply. Paste a lease clause and it rewrites the paragraph. Open a second window while the first draft is still landing, and you get a second draft. The screen looks busy. Nothing has left the building.
The week is not "use Claude less." The week is one live ticket in one Claude session until a named person sends. You already have the queue. Claude is the thing you will actually open. The constraint has to sit on that product, because Claude will not sit on it for you.
Your second chat is not a closer
You can start a new Claude thread in the time it takes to switch tabs. A new terminal is the same move with a different frame. Each session will take the next paste and keep going. Review then becomes the job, and review of ten half-done drafts is slower than finishing one.
Vasuman Moza (@vasuman), who used to ship this class of tool at Meta and now watches companies try to run it, put the cost in plain language. The harm is not that Claude is weak. The harm is that it makes splitting your attention feel like output.
@vasumanThe biggest damage AI is doing right now is making you want to multitask in the name of productivity.
Vasuman Moza
He is describing the exact loop a shop this size already feels when the queue is ugly. Movie on in the background, prompt Claude every few minutes. Ten tasks on the board, ten terminals. Each task gets less of you. The drafts exist. The send does not.
So this week you run Claude on real work, one session, one live ticket. Not a new app. Claude, until a human sends.
The live ticket has a person on it
Pick who owns the queue this week. In a team of twenty that is often the support lead. If leases and disputes sit with ops, that person owns those files the same way. One owner per work type. Two owners total is fine. Ten people "helping in Claude" is how you get ten windows.
The queue owner opens Claude once on the ticket that is actually live. Live means a customer, a vendor, or a file is waiting on a send from you. Not a curiosity. Not a side rewrite of last month's policy while a refund sits unsent.
Claude's job in that session is narrow. Summarize the thread. Draft the reply. Flag the clause that does not match the file. Suggest the next sentence. It will do that cheerfully in one chat or in ten. You are the one who chooses one.
The named sender is a human. Claude does not send. If the queue owner and the sender are the same person, say that out loud on Monday so nobody treats the draft as gone. If they are two people, the sender reads the Claude draft against the ticket, then hits send. Money, apology, and legal language stay with that person. A lease does not leave because Claude made it shorter. A dispute does not close because Claude sounded calm.
Deep work gets a calendar block, not a second tab. Leases, disputes, and the tickets that need a file pulled all belong in a named hold. During that hold, Claude may be open. It may be open on that file only. The rest of the queue waits. Claude will let you peek. You do not.
Figure 1
The handoff is short on purpose. Owner names the live work. Queue owner either shuts the extra Claude or never opens it. Sender ships. Owner reads the extra-window log on Friday. Nobody needs a new stack to run that.
Prompt the pile after the send
You still have to clear the queue. Claude is still the right tool for that sitting. The failure is dripping prompts all day while you half-watch something else. Sit the batch in a calendar block, and stay in that Claude thread until the named sender has sent, or until you write down why it cannot send today.
Then, and only then, take the next ticket. Same Claude account. New chat is allowed after send. A second chat in parallel is not. If five tickets are the same kind of "where is my order," you may paste the pattern into the thread you just finished and ask Claude for the next draft. That is a batch. Ten separate terminals on ten open wounds is not.
Vasuman's picture of ten terminals is the tell. Claude will accept all ten. You will enjoy none of them, and Friday you will still be "just finishing the last one." The batch is a time box, not a fan-out.
If a prompt is still generating and you feel the itch to start another, that itch is the whole point of this week. Close the extra tab. Wait. Send. Then open the next.
Friday's extra windows
Keep a single line in the place you already write work notes. Date, ticket or file name, extra Claude chats or terminals opened before send. Nobody has a credible figure for how many of those chats a team this size abandons in a week, so count yours. A follow-up in the same thread is not an extra. A new chat is. A new terminal is. The owner reads that log Friday, not as a score, as a picture of whether the rule held.
| Measure | Count |
|---|---|
| Extra Claude chats opened before the live ticket was sent | |
| Deep-work blocks that grew a second Claude window |
If Friday's first row is zero, keep the rule. If it is not, do not add software. Name the person who opened the extra window and put them back on one live ticket Monday.
Run Claude on one live ticket this week
Do this on Monday, on the real queue, not on a sample prompt.
- Name the queue owner and the named sender for the week. Same person is allowed.
- Name the deep-work files: leases, disputes, or the tickets that need a pulled folder. Block them on the calendar.
- Open Claude on the oldest live ticket only. Work that thread until send, or until the blocker is written down.
- After send, batch the next similar tickets in the next sitting. Do not open a parallel Claude.
- Log every extra chat or terminal before Friday.
Stay in the first session until a human has sent. Claude can draft the next one after that. It cannot be the closer, and it will not tell you when you have opened too many.
You can run this from the desk you already sit at.
Sources
If one workflow is eating your week, tell me which one. I'll tell you if it's worth deploying — and if it isn't.
Message Mikko on LinkedIn