Support

We are slowly and steadily making our way back down to inbox zero on the support side, having spent most of the past month and a half playing catch-up. This is largely uninteresting (the backlog, not the tickets themselves!): support is, at the end of the day, fairly easy to model under queuing theory — if inflow outpaces outflow, things are bad, if outflow outpaces inflow, things are good.

Anita has been starting to label and categorize our tickets so as to triage hotspots. Our three most common types of issue are Paid subscriptions, Deliverability, and Billing/Pricing, which kind of makes sense — they’re all open-ended, they’re all subject to weird external factors: much of “Paid subscriptions” is really “Cosplaying as Stripe support.

This reminds me of the last time we did this exercise two years ago, and realized a huge amount of our support burden was simply “we were helping people write CSS and that’s not sustainable,” which led to the simple solution of “we no longer help people write CSS.” Stripe is not quite as open-ended as CSS, but I think from both a product and positioning perspective we have to pick our battles a little bit more aggressively (see Rendering; DuckDB; Stripe; DNS ). Scaling support is about leverage; the number of customers a single person can service in aggregate must trend downwards over time, and it’s hard to build leverage on shores that aren’t our own.

Plain

I don’t think I’ve actually written about Plain that much, which is the replacement we chose for HelpScout late last year. Plain is a nice tool; enough time has passed that we can feel happy rather than anxious about having made the right choice. Their positioning is very AI, which belies the fact that they’re one of the few help desk tools that doesn’t shoehorn you into using them as a CRM because that’s where the money really is (a la Intercom, Zendesk et al): moreover, they’re priced well (we pay them less than we would be paying Helpscout) and the product is good.

If we were just starting out today, I don’t think I’d choose Plain; I’d probably choose Jelly , which lets you take stuff out of your personal inbox without loading you down with a bunch of YAGNI. But Plain is really good once you are at the point where it makes sense to technically invest in your support tooling.

Managed DNS

The fancy delegation-based mechanism I mentioned in Rendering; DuckDB; Stripe; DNS has officially soft-launched, thanks to some heroics from Ben! It breaks my brain that it works and is ergonomic. I am already scope creeping it to hell: wouldn’t it be nice, for instance, if we shoehorn hosting domains into it somehow, and oh Google Postmaster Tools is probably launching programmatic registration this year … but, beyond that, I think this is a great example of useful leverage. We build a thing that solves a pain in the short term and gives us scaffolding to do interesting work in the longer term.

Embedded Stripe

Safely ensconced behind a query parameter, our in-app checkout (as seen above) is now live. I would be lying if I didn’t say that, even after all this years, I didn’t have any lingering bit of trepidation before turning something like this live: and the advantage of being able to phase something like this in is that we can do a bunch of live manual testing and give folks the ability to flag themselves in under some sort of timeline before migrating the full amount of traffic.

When launching something like this, which involves a bit of in-flight avionics, I try to sequence things in the following order (once I have the sufficient level of consequence for each piece):

1. The backing data model

2. Any one-time migrations to update the data model

3. Inert business logic changes

4. Inert component and front-end changes

5. The duct-tape to tie everything together

This lets me feel like I have significant amounts of forward momentum without significantly increasing the risk profile: phrased differently, the trick is to try and get as much of the actual code change across the line without introducing any risk whatsoever.