Five-second answer: do not just speed up tasks—shorten how long undecided tasks live in your head
The expensive part of a ten-minute complaint is often not the ten minutes.
It is spending three days thinking:
- Should I send it today?
- Should I wait?
- Should I ask for compensation now?
- Is that too aggressive?
- Should I add another request after they reply?
- Oh right, I still need to deal with that.
Ten minutes of actual work can occupy seventy-two hours of mental residence.
That is the human equivalent of an idle-looking computer with background processes quietly eating RAM.
A better rule is simple:
When a problem appears, decide every request you can reasonably decide now, send them together, and hand the turn to the other party. Until new information arrives, your process is done.
Case study: a roughly ¥20,000 webcam comes back as “defective”
Consider an anonymized e-commerce seller case.
A webcam worth roughly ¥20,000 was marked as defective and could no longer be sold. It was returned to the seller. Because “defective” means something should actually be wrong, the seller opened it and connected it to a PC.
The computer recognized it. The camera launched. Video appeared. Under ordinary use, it worked.
Cue the internal reaction: “What the hell?” Somewhere in the mind, a small animal is screaming at full volume.
But volume is not the important part. Structure is.
- The product cannot simply be relisted because it was classified as defective.
- Testing required opening it, reducing the value of an unopened new unit.
- At roughly ¥20,000, even one incident matters.
- If the same process repeats, a seller could repeatedly bear the risk even when the item works.
- Therefore compensation and the treatment of future recurrences should be requested in the first message.
From receiving the unit to testing, organizing the issues, drafting the request, and sending it took about eight minutes.
The impressive metric is not the number eight.
The impressive part is that after eight minutes, the case is no longer living in your head. It is sitting in somebody else’s queue.
Update: the root cause was “the labeling service covered the authentication code with another label”
A later investigation changed the case materially. The platform explicitly acknowledged that its labeling service had placed a product label over the Transparency code, and that this was the platform's responsibility.
The sequence was therefore: paid labeling service → label placed over Transparency code → code became unreadable → item classified as defective/unfulfillable and returned → no specific root-cause explanation → seller opened the webcam to determine whether the hardware itself was defective → ordinary operation was normal → later investigation identified the labeling error.
In other words, the system had hidden the code itself and then complained that it could not see the code. A beautifully self-authored bug.
The platform offered reimbursement for the labeling fee and return fee, but excluded the loss in unopened-new value on the theory that opening and testing the unit had been the seller's own decision. That changed the dispute. The question was no longer who caused the original failure; that had already been admitted. The question became why the foreseeable loss in product condition could be severed from the admitted operational error.
If the return notice had said that the platform's own label was covering the Transparency code, there would have been no reason to open the webcam to diagnose a hardware failure. Later, the platform itself also requested photographs of the item condition, barcodes, and serial number, and used photographs of the opened unit as investigation evidence.
The seller therefore requested another review of the product-value loss and asked for the specific policy basis if that loss was still to be assigned to the seller. As of September 10, 2026, support had accepted the case for internal review and said the next update would be sent by email.
The workflow lesson is the same: keep the objective fixed, update the claim when the evidence changes. New fact → new model → move the dispute from root cause to scope of loss → send the revised requirements → hand the turn back. Support is not a debate club; it is debugging.
What became faster was not typing; it was decision residence time
The old pattern looks like this:
problem
↓
what should I do?
↓
when should I say it?
↓
how much should I ask for?
↓
maybe tomorrow
↓
remember it randomly
↓
think again
↓
still not sent
The new pattern:
problem
↓
verify facts
↓
list loss, requests, recurrence risk
↓
combine into one message
↓
send
↓
your turn
The major reduction is in future decisions.
“Should I ask for compensation?” “When should I ask?” and “Should I send a follow-up?” are not left running overnight. The requirements are shipped up front.
Why “send all requests up front” is powerful
Sending complaints one fragment at a time turns support into a serialized drama.
Episode 1: Why was this marked defective?
Episode 2: Also, can you compensate me?
Episode 3: I cannot relist it.
Episode 4: What happens if this occurs again?
Episode 5: About that thing from last week…
Each episode requires your brain to remember the next plot point.
A better first message contains:
- facts: what happened
- verification: what you tested
- loss: what value or opportunity was lost
- request: what resolution you want
- recurrence: what should happen if it repeats
- done condition: what response would close the case
At that point the complaint has quietly transformed into a requirements document.
Turning it into “their turn” is basically asynchronous API design
The mental model is:
POST /support
body:
facts
loss
request
recurrence
desired_resolution
→ 202 Accepted
→ local process exits
Do not poll your own brain every hour.
Do not repeatedly ask, “I wonder what support is doing.”
Wait for an event. A reply arrives. Then resume.
Event-driven, not permanent monitoring.
You do not need Kubernetes in your skull, but stealing the architecture is allowed.
Research 1: unfinished work tends to follow people after work
This is more than a software metaphor.
Research on work-related rumination has repeatedly linked unfinished tasks or low task accomplishment with greater rumination and poorer psychological detachment. A 2025 experience-sampling study found that lower task accomplishment was related to evening rumination and reduced detachment through end-of-day frustration. Earlier diary research also linked unfinished tasks with rumination and poorer sleep.
That does not mean “sending customer support messages within eight minutes improves health.” The evidence is not that specific.
It does support the broader idea that a task can be physically paused while remaining cognitively active.
Research 2: externalizing “do this later” can reduce prospective-memory demands
Remembering to execute an intention later is called prospective memory.
Reminders, calendars, notes, and environmental cues are forms of cognitive offloading. Experiments show that people use reminders more when memory demands are higher, and reminders can improve completion of future intentions.
There is an important distinction between a reminder and a fully scheduled action.
A reminder says, “It is time; now you still have to do it.”
A scheduled email delegates both timing and execution in advance.
That suggests a useful principle:
If a step can be completed now instead of merely remembered later, completing it now leaves even less future cognitive work.
Sending the complete request today is stronger than reminding yourself to add compensation next Tuesday.
Research 3: offloading is not magic
External systems have a trade-off.
A 2026 experiment found that when people offloaded a prospective-memory intention to reminders, later performance on that intention could become worse once the reminder was removed than for people who had never offloaded it.
So “I externalized it” is not the same as “I will still remember it if the system disappears.”
Good offloading therefore needs a reliable external queue:
- sent-message history
- ticket or thread
- reply notification
- a clear condition for your next action
If you remove something from your brain, give it a real place to live.
Throwing it into the void and calling the void “the cloud” is not architecture.
This is not emotional suppression: “What the hell?” just does not get the driver’s seat
Fast resolution does not require becoming emotionless.
You can still think:
“What the hell?”
The difference is what happens next.
what the hell?
↓
verify facts
↓
describe the loss
↓
convert it into a request
↓
send
↓
done
Anger is useful as anomaly detection.
It is less useful as the person typing the support ticket.
Use it as fuel, not as the driver.
Practical template: fill seven fields, then send
1. What happened?
2. What did I verify myself?
3. What should the normal state have been?
4. What loss or disadvantage occurred?
5. What do I want the other party to do?
6. Why would recurrence be a problem?
7. What response would close the case?
Once those are filled, send.
“Let me keep this in my head until the prose matures” is usually not wine aging. It is a RAM leak.
Change the metric: measure mental residence time, not just task duration
Useful metrics include:
- Brain Residency Time: time from problem detection to externalization or sending
- Pending Decision Count: how many “I will decide later” items remain
- Revisit Count: how many times you mentally reopen the same case
- Owner Status: who currently has the ball
- Trigger Clarity: what event will make you act again
A task that takes ten minutes but lives in your head for three days is not a ten-minute task in any meaningful psychological sense.
Do not turn “send now” into a religion
Some cases deserve slower verification:
- major legal consequences
- medical or safety decisions
- irreversible contracts or submissions
- unclear facts
- situations where anger may produce threats, accusations, or unreasonable demands
Immediate processing does not mean acting without thinking.
It means doing the necessary verification and then refusing unnecessary delay.
In the webcam example, the seller did not merely assert that the device was fine. They connected it to a computer, confirmed recognition, launched the camera, and confirmed video output.
Fast is not the same as sloppy.
Final rule: reduce the number of “what should I do later?” processes in your life
AI is useful because it can draft messages quickly.
But the larger gain is that tools can transform vague future decisions into a specification now.
A problem appears.
Internally: “What the hell?”
Verify.
List every reasonable request.
Send.
Then:
“Your turn.”
That is not avoidance. It is completion of your side of the workflow.
Your mental RAM is finite.
Customer support does not need to become a startup program.
