Draft the monthly investor update

The monthly investor update takes two hours and about ten minutes of those are writing. The rest is opening the payments dashboard, exporting the pipeline, finding the plan spreadsheet, working out the variance, and scrolling back through sent mail trying to remember what was promised last time. It slips a week, then two, and the update that eventually goes out is thinner than the one intended.

Every input is already a system of record with an API. The numbers exist, the plan exists, and last month's promises are sitting in a sent email. Assembly is the whole cost, and assembly is not the part that needs a founder, which makes it the part of an investor update worth automating.

What goes into the monthly investor update

The run starts on the first working day of the month, once the previous month has closed in every system it reads. It pulls from four places.

• Revenue actually collected, from Stripe: new recurring revenue, recurring revenue lost (split into cancellations and downgrades, because they are different problems), the net movement and the closing figure. One-off revenue stays separate, since folding it into recurring overstates the thing investors track most closely. The currency and the exact date range are stated.
• Pipeline, from HubSpot: deals opened, won and lost, open pipeline by stage, and the movement in the total. Any single deal large enough to move that total on its own is called out, so a pipeline jump that is really one deal reads as one deal.
• The plan, from the month's targets in Google Sheets. Each target sits beside its actual, in absolute and percentage terms. A target missing from the plan is reported as missing, never inferred from the previous month.
• Last month's promises, from the previous update in Gmail's sent mail: every hire, launch, target or milestone it committed to.

The draft then follows a fixed order: headline numbers, variance against plan, last month's commitments and their status, pipeline, then asks.

Why revenue comes from the payments system

Revenue comes from the payments system and only from the payments system. The CRM knows what was sold, which is a different number from what was collected. Failed payments, prorations, mid-month downgrades and refunds all live in the gap. Investors compare this figure month on month, so a source that quietly drifts from cash is the one error here that compounds instead of being corrected next time.

Variance against plan, stated without spin

Each variance is stated as a number. Where a cause is visible in the data, it gets one clause and no more: "Revenue 12% under plan; two enterprise renewals slipped into the following month" gives an investor something to work with, while "slightly behind but momentum is strong" gives them nothing to check. The draft puts no adjectives on its figures. The recipient can decide whether 12% is good.

Keeping an investor update honest month after month

Last month's commitments are regenerated from the previous email, which is what keeps an update honest over a year. For each one, the draft says what actually happened: done, slipped with a new date, or dropped with a reason. That section is the first to go missing in a bad month, not through dishonesty but because memory retrieves the promises that were kept. Reading them off the sent message means the list is the same list whether the month went well or badly.

Leaving explicit gaps instead of estimates matters more here than almost anywhere else. A missing figure is a visible prompt to go and find it. An estimated figure is indistinguishable from a real one on the page, and it becomes the baseline the next month is compared against, which is how a small convenience turns into a number nobody can reconcile two quarters later.

The result stays a draft, with every figure carrying its source and date range. The qualitative half, what the numbers mean and what comes next, is the part a founder should be writing, and it is left to them.