Most fundraising follow-up is too late

The clock you're racing

An investor's interest after a good meeting is not a steady level that holds until you nudge it. It's a decay curve. Right after the meeting, their mental model of you is fresh: they remember the specific thing that made them lean in, the number that stuck, the reason this could be the one in the category they back. Every day after that, without a new input from you, the model gets a little vaguer and a little easier to deprioritize against the founder who pitched them yesterday and is fresh now.

Reminders ignore this entirely. A reminder is a function of calendar time: "it has been seven days, ping the founder." Decay is a function of relationship time: "this thread is two-thirds cold and needs an input now." The two only line up by accident. A week is far too late for a partner who asked for the data room and expected it that afternoon. A week is far too early to re-touch a fund that told you, credibly, they revisit after their next partner meeting in three weeks. One reminder interval cannot be right for both, because the decay rate isn't set by your calendar. It's set by the stage the conversation is in.

So the founders who run follow-up on a fixed cadence, "I check in every week," are right on cadence and wrong on timing for almost every thread at once. The fast-decaying threads get followed up after they've already gone cold. The slow-decaying ones get nudged before there's anything to say, which reads as anxious and trains the investor to expect content-free pings. The cadence feels disciplined. It's disciplined against the wrong variable.

Freshness windows: the timing model that replaces reminders

Replace "follow up every N days" with a per-thread freshness window. A freshness window is the span of time after an interaction during which a follow-up still lands on a warm model and resets the curve. Inside the window, your input arrives while they still remember why they cared, and it pushes interest back up. Past the window, the same input lands on a cold model, reads as "circling back," and gets the polite deflection.

The width of that window is set by the stage of the conversation, not by your schedule. Three forces move it:

The temperature of the last interaction. A partner who asked for the data room is hot and decays fast: the window is hours to a couple of days. A fund that took a polite first call but didn't lean in is lukewarm and decays slowly, because there wasn't much heat to lose.

Whether there's an open loop. If they asked you for something, the window is short and hard, because every day you don't deliver is a day they read as "no momentum" or "couldn't execute." An unfulfilled ask decays faster than ambient interest.

Their own stated clock. "We meet as a partnership on Mondays" or "I'm heads-down on a close until month-end" resets the window to their rhythm. Following up before their clock turns is noise. Following up the day it turns is timing.

The move this gives you is a different question. Not "has it been a week?" but "which threads are inside their window today, and which are about to fall out of it?" You follow up the threads about to fall out, with the input that fits their stage, before the window closes. The reminder asks when you last touched the thread. The window asks how much warmth is left. Only the second one is racing the right clock.

The stages and their windows

Here is the table the brief calls for: conversation stage, how fast it decays, the freshness window to act inside, and the follow-up that fits the stage. The day counts are starting defaults, not laws. The point is that they differ by stage by an order of magnitude, which is the whole reason a single reminder interval fails.

Two patterns fall out of the table immediately. First, the threads with the most heat have the shortest windows, which is the reverse of how reminder-based follow-up treats them. The hottest threads, the open ask and the post-partner-meeting, are the ones a weekly cadence handles worst, because by the time the reminder fires they've fallen out of a window measured in hours or days. Second, the lukewarm threads have long windows, and chasing them early is the most common self-inflicted wound: you nudge a slow-decaying thread before you have anything new, and you spend the one re-touch you had on a content-free ping.

Before / after: the partner who asked for the data room

BEFORE (followed up on schedule, answered too late)
  Day 0:  Strong meeting. Partner: "send me the data room, I want
          to dig in." You set a reminder for day 7 so you "don't
          forget."  Stage = open ask. True window = same day–48h.
  Day 7:  Reminder fires. You send a clean data room with a nice
          note. Right on your schedule. Six days past the window.
  Day 8:  "Thanks for sending, we'll take a look and circle back."
          The lean-in is gone. The thread is now a maybe.
  -> The reminder worked. The timing failed. Day-7 was right for
     your calendar and 5 days too late for the partner's curve.

AFTER (followed up inside the window)
  Day 0:  Same meeting, same ask. You read the stage: open ask,
          window is hours. No day-7 reminder. The next action is
          "today."
  Day 0,  Data room sent same evening. "Here you go. Tab 2 is the
  6pm:    retention you flagged; tab 4 is the CAC build. Want to
          walk either Thursday?" + two slots.
  Day 1:  Reply: "Tab 2 is great. Thursday works." Thread stays hot
          because the input landed while the model was still warm.
  -> Same room, same company. The only variable changed was whether
     the follow-up landed inside the window or after it.

The data room didn't get better between the two versions. The company didn't change. The single difference is that one founder followed up when their reminder said to and the other followed up when the investor's curve said to, and that gap, five or six days, was the whole round for that thread.

The artifact: a stale-thread dashboard

A reminder list tells you what's overdue by your clock. What you need instead is a view that ranks threads by how close they are to falling out of their freshness window, so you act on the one about to go cold today rather than the one whose reminder happens to fire today. That's a stale-thread dashboard. You can run it in a spreadsheet. Here's the shape and how to read it.

STALE-THREAD DASHBOARD  (one row per live thread)

COLUMNS
  Thread            investor / fund
  Stage             from the stages table above
  Last contact      date of last real interaction
  Open loop?        what they asked for, if anything (blank = none)
  Window (days)     freshness window for this stage
  Days left         = Window - (today - Last contact)        <-- the sort key
  Status            FRESH / CLOSING / STALE / COLD (derived from Days left)
  Next input        the specific thing you'll send (not "check in")
  Owner             a name. you, cofounder, advisor.

STATUS RULE (derive, don't eyeball)
  Days left >  2          -> FRESH    (do nothing; sending now is early)
  Days left  0 to 2       -> CLOSING  (act today, this is the live work)
  Days left -3 to -1      -> STALE    (rescue: needs a real input, not a nudge)
  Days left < -3          -> COLD     (diagnose / one honest re-open / let rest)

SORT
  By Days left ascending. The top of the list is what you do today.
  CLOSING rows first, then STALE. Ignore FRESH. Triage COLD weekly.

WORKED EXAMPLE (today = day 10 of the round)
  Thread     Stage              Last  Open loop      Win  Left  Status   Next input
  Fund A     open ask (room)    d8    data room      2    +0    CLOSING  send room tonight, point to tab 2
  Partner B  post partner mtg   d7    —              3    +0    CLOSING  send the metric the room will debate
  Fund C     post 1st mtg warm  d9    —              3    +2    FRESH    nothing yet; recap already sent
  Fund D     lukewarm 1st mtg   d2    —              12   +4    FRESH    wait for a real proof point
  Fund E     revisit post-IC    d4    after their IC their clock   their clock  re-open day their IC passes
  Fund F     was hot, silent    d3    intro promised 3    -4    COLD     deliver the intro OR one re-open

The dashboard's whole job is the Days left column and the sort. It converts a pile of threads into one ordered list of what to touch today, ranked by warmth remaining instead of by how long it's been. Two rows do the heavy lifting. The CLOSING rows are the work: threads inside the last 48 hours of their window, where a well-aimed input still lands warm. Do these first, every day, before anything else in the round. The FRESH rows are the discipline: a thread with days left is one you leave alone, because touching it now is the anxious early nudge that trains investors to ignore you. The reminder model has no FRESH state. It only knows "due" and "not due," which is why it makes you both late and twitchy at the same time.

Where RoundOS fits

You can keep this dashboard by hand, and at five live threads you should. One spreadsheet, the stages table taped next to it, recompute Days left each morning, work the CLOSING rows first. That alone beats any reminder app, because it sorts by warmth instead of by calendar.

It breaks at scale, because the inputs the Days-left math needs are scattered across the places the round actually lives. The stage of a thread is buried in a meeting note. The open loop is a line in an email from eight days ago. Their stated clock ("after our IC") is in a call transcript. The last-contact date is wherever the last touch happened, inbox, calendar, or DM. To keep this dashboard accurate by hand, you'd reconstruct stage, last contact, open loop, and window for thirty-plus threads from four sources every morning, and the day you skip it is the day the CLOSING thread you needed falls cold.

RoundOS reads thread state from those sources directly: email, calendar, meeting notes, investor spreadsheet. It infers the stage and the last real contact, carries the freshness window for that stage, and computes days-left so the dashboard stays current without you rebuilding it. What it surfaces each morning is the CLOSING list: the handful of threads about to fall out of their window today, each with the stage-appropriate next input already drafted from the actual context, so you review "send the room, tab 2 answers the retention question" instead of staring at a reminder that says, uselessly, "follow up with Fund A." The job is one thing: make sure no warm thread cools while it sits behind a reminder that hasn't fired yet.

Do this today

Stop sorting your follow-ups by how long it's been. Build the dashboard for your live threads right now: one row each, tag the stage, write in the freshness window from the table, compute Days left, and sort ascending. Whatever sits in CLOSING is your work for today, ahead of anything a reminder is telling you. Then do the prevention half: for every hot thread, especially any with an open ask, delete the day-7 reminder and replace it with the real window, which for an open ask is today. The rule that replaces reminder-based follow-up: race the investor's decay curve, not your calendar, and send the input while the window is still open.

When you want days-left computed for every thread from the sources your round already lives in, with the closing ones surfaced each morning and the right next input drafted from context, connect those sources and let RoundOS run the dashboard with you.

Freshness windows + stale-thread dashboard

TIMING MODEL: follow-up runs on the investor's decay curve, not your calendar.
A reminder measures time since you last touched the thread.
A freshness window measures how much warmth is left. Race the second one.

FRESHNESS WINDOWS BY STAGE (starting defaults, tune from replies)
  Open ask outstanding ........ same day–48h   (lateness = can't execute)
  Post partner meeting ........ 2–4 days
  Post first meeting (warm) ... 1–3 days
  Cold intro / intro accepted . 2–4 days       (nudge connector, not investor)
  Post data-room / diligence .. 3–5 days
  Verbal interest, no terms ... 4–7 days
  Post first meeting (lukewarm) 10–14 days      (wait for real proof, don't chase)
  "Revisit after [their event]" their clock     (re-open the day it turns)

DASHBOARD (one row per thread, sort by Days left ascending)
  Thread | Stage | Last contact | Open loop? | Window | Days left | Status | Next input | Owner
  Days left = Window - (today - Last contact)

STATUS (derive from Days left)
  > 2      FRESH    leave it; sending now is the anxious early nudge
  0 to 2   CLOSING  act today, this is the real work, do it first
  -3 to -1 STALE    rescue with a real input, never a "circling back"
  < -3     COLD     diagnose / one honest re-open / let it rest

THE TEST (before any follow-up)
  "Is this thread inside its window, and am I sending the input its stage needs?"
  Inside + right input  -> send now.
  Outside, no new input -> you're chasing on a cold model. Don't.

THE RULE: the follow-up that matters is the one before the thread goes cold,
          not the one your reminder fires after it already has.