adlk.ioEarlier this month a customer sent me five mails in two days. Pro plan, macOS, all about the new calendar. His confirmed meetings showed up struck through, as if he'd declined them, and he didn't just report it. He worked out the cause himself: if anyone declines, you show it as declined. He was exactly right. The code checked whether any attendee had declined a meeting instead of whether he had.
His last mail had the sharpest point. Franz had been writing its own labels into his Gmail account, without a setting, without an opt-in, and invisible inside Franz itself, because Franz filters its own labels out of the folder tree. He only ever saw them in Gmail. Right again.
Overnight, that thread turned into four repair jobs. The nightly loop that tests my releases verified the fixes, and by morning a drafted reply was sitting in my inbox, waiting for me. I rewrote most of it, like I do with almost every draft, and sent it myself.
That last part is the point of this post.
The machine prepares more than ever
If you've read the earlier parts of this series, you know what I've handed over. The machine tests my code at night and it validates the updates I never had time to check. Support looks like the obvious next thing on that list, and a lot of people would hand it over completely.
Mine is quite far along, to be fair. Every incoming mail is classified by a model. Nearly every mail gets a draft reply, written by a model that's grounded in the support knowledge base, in past resolved cases and in the customer's actual account data, and that's forbidden to state a fact it can't source from one of those. It learns tone from 20 of my past replies, and it's allowed to copy how I sound but not what I claim. The infrastructure behind this grows almost every week, and unlike the dependency loop from part three, it keeps what it learns: every answered thread gets distilled into memory for the next draft. When a mail describes a real bug, an agent pulls the whole thread, reads the log files the customer attached and investigates, quite often before I've read the mail at all. The models are Mistral's, hosted in Europe, which is a deliberate choice and an old story by now.
And still, nothing goes out without me. There's exactly one way a reply can leave the system: the send button in my review screen, which sends whatever is in the editor the moment I press it. No automatic path exists. That's not a policy I have to remember to follow, it's the only door that was built.
Here's what that looks like in numbers. Since May, 644 support mails arrived. The machine drafted an answer for 615 of them. 402 replies went out through the inbox, another 66 I wrote straight from Gmail when that was faster. And of the 405 drafts that reached a customer, 16 went out the way the machine wrote them. All the others I rewrote, some lightly, most not: the median draft takes 229 keystrokes of editing before I approve it.
The drafts are getting better at the facts. In July the median was 256 keystrokes; since the drafter gets fed real context, the customer's history, past resolutions, what actually shipped, it's down to 119. What the drafts still get wrong is me. For a while the drafter kept writing that "the team" would look into things. It did that 19 times before its instructions got a line that shouldn't have been needed: I'm Stefan. I am the team.
Its style rules also ban em-dashes. 46 drafts had them before that rule existed. Some tells you only learn to see once they're aimed at you.
The number I'd least want to lose in all of this is that keystroke count. It sounds like a strange thing to measure, and it's the entire improvement loop: without it I'd never know the grounding work halved the editing, and I won't know when the drafter has earned more trust either. There's a bar written down for that too: 8 of the last 10 drafts going out untouched. Today the answer is a clear no, 16 of 405, and I know it precisely instead of feeling it. Most people who hand work to a machine never measure what comes back, and then the only thing they can say about their setup is that it feels better or worse. I'd rather know.
The inbox pays off in a second, quieter way: it keeps making the support form better. Answering the same problem again and again tells me exactly what the form should catch before a mail ever gets sent. The most common case by far: the person writing in is on an old version. We ship quite often, so the chances that a problem is already solved are high, and the form's job is to get people to that update before they spend time writing to me. Deflection sounds like a dirty word in support. It isn't if the person ends up helped faster than I could have answered.
When I actually answer
Because every send is mine, there's a record of when support actually happens. This is every reply I've sent through the inbox since May, by weekday and hour:
There are no office hours in it. The tricky cases, the thread that needs a decision, the customer who found a real bug, go into the coffee shop mornings you've seen in this series, next to the merges and the arguments that piled up overnight, because that's where my mind is. The routine replies happen wherever the day has room: evenings carry most of them, Saturday late morning is the single busiest slot, and a handful went out after midnight. The median mail still waits only about two hours for its answer.
I want to be precise about what this chart proves, as it's the same argument the whole series makes. Support mail is patient work. Nobody expects an answer in 90 seconds, and no reply in that chart was pushed into a particular hour by anything except when I had time and something useful to say. The machine does the impatient part, the classifying and investigating and drafting, in the minutes after a mail arrives. The patient part stays with me, and it fits around my life instead of interrupting it.
What the numbers can't tell me
So why keep it at all, if the machine is this far along?
I look at the analytics every morning. The numbers tell me what happened. The mails tell me why, and every so often the two disagree completely.
The clearest case: for months, every Linux build of Franz from 6.2.0 on crashed at launch on newer Ubuntu versions, because of a packaging change that looked harmless. Analytics never saw it, and it never could have. The app dies before any telemetry exists, so those users don't show up as a dip in a chart. They just stop existing in the data. The only place they existed was my inbox, in mails saying Franz won't start. That's what finally got it root-caused and fixed; the fix ships with the next release.
It cuts the other way too. In July a release removed the automatic trial, and trial signups dropped off a cliff. Not one person wrote a mail about it. Why would they: nobody complains about a trial they never knew existed. The funnel numbers caught it, later than they should have, and the mails alone never would have.
So this isn't an argument against analytics. Each side is blind exactly where the other one sees, and reading the mails myself is how I know which of my numbers to distrust. I can't hand that over. I also don't want to: some of those 644 mails are people writing just to say thanks, and there's no dashboard for that either.
The other work I kept
The second thing I never handed over is concept work. Franz Mail is going to change completely in the near future, and that thinking happens everywhere. But the arguments that matter, the ones that have been building up for days, tend to get settled at the coffee shop. First with a model. Then the same argument again with whoever is around: founders, friends, developers, product people. Sometimes the founder of the coffee shop, who thinks about juggling channels and managing people in words I'd never reach for. Sometimes a stranger joins in. Vienna is small.
The two rounds catch different things. A model will argue with me all day and still let me keep a bad idea. Someone who has shipped something usually won't.
And these arguments are concrete. One of them: the priority inbox has no way to say "done" that doesn't make things worse, as the current exits either archive the mail away or teach the classifier that the sender doesn't matter. Another one: when you ask a mail app for all invoices from Q2, a ranked top-50 result that presents itself as complete is lying to you, and the app should be able to say when it truly means "all". No dashboard will ever answer either of those, and both are expensive to get wrong.
The rule underneath
Deciding what to hand over has turned out to be the actual work, and after two posts of handing things over, this one is the mirror image. The rule I've ended up with: hand over the work where being wrong is cheap and gets caught, and keep the work where being wrong is expensive and invisible. A failing test is cheap and gets caught the same night. A wrong read of what customers want is expensive, and no alarm will ever go off.
The machine can prepare all of it, the diagnosis, the draft, the evidence. What stays mine is the judgment and the send.
The daily numbers I mentioned come from an agent with a job title, and she publishes her own miss rate. That's part five.
If you're a founder working out how much of this you can hand over, and where the line should sit, that's the work I do with teams. Let's talk.
