How to Write a Decision Log Entry for a Fundraise

Not everything deserves an entry. Log choices that are hard to reverse, allocate real time or money, or lock you into a story you will have to defend for months. The practical filter from project management practice is: strategic impact, significant resource allocation, or risk that cannot be easily undone monday.com.

For a fundraise, three decision types pass that filter:

Smaller choices can live in a single line inside the nearest big entry. "We dropped investor X after the second call because they wanted a lead role and we needed a co-lead" belongs in the target list entry, not in its own document.

There is a useful cross-check here. The narrative you write down should map onto the same building blocks an investor will test: customer segment, value proposition, channels, revenue logic, and cost structure. Those nine blocks are the standard Business Model Canvas set described by Strategyzer and catalogued on Wikipedia. If your narrative entry cannot say which block changed and why, it is probably a styling decision, not a strategic one.

Every entry answers four questions. Keep them in this order every time so a reviewer (human or model) can find them.

1. What options were considered? List at least two real alternatives, including the one you picked. "Option A: lead with the platform story. Option B: lead with the cost-savings story. Option C: lead with the founder story." If you only ever consider one option, you did not make a decision, you made an announcement.

2. What evidence did you use? Name the source and the date. "Twelve customer interviews in which nine described the problem as headcount, not cost." "Three comparable rounds at a similar stage with the same revenue profile." Evidence should be checkable by someone who was not in the room.

3. What assumptions did you make? State what you believe but have not proven. "We assume infrastructure buyers read the same newsletters as application buyers." An assumption is a bet, not a fact, and the log should make that distinction visible.

4. What would change your mind? Give a specific trigger. "If fewer than five of the next twenty target investors ask about the platform story in the first call, we rewrite the narrative." Vague triggers ("if things go badly") are useless because nobody can act on them.

Here is the shape as a fillable block:

Decision: [one line, verb first]
Date: [YYYY-MM-DD]
Owner: [one name, not a team]
Status: [proposed | decided | revisited | reversed]

Options considered:
- A: ...
- B: ...
- C: ...

Evidence used:
- [source, date, one-line finding]
- ...

Assumptions:
- ...
- ...

Revisit trigger:
- ...

Linked artifacts: [deck version, target list tab, model file]

Two rules make this durable. First, one decision per entry. Second, the owner is a person, not a committee, because accountability only works when a name is attached, a point made in most decision log guidance like Craft's template notes.

Suppose you run a 14-person infrastructure company and your early customers are platform teams. You have two stories available. Story one: "we cut cloud spend by 40 percent." Story two: "we let platform teams ship internal tools without hiring." Both are true. You can only lead the deck with one.

The entry might read:

• Decision: Lead the fundraise narrative with the internal-tools story, not the cloud-spend story.
• Options: (A) internal-tools story, (B) cost-savings story, (C) both, presented as a portfolio.
• Evidence: Twenty-two customer calls, of which seventeen mentioned hiring constraints unprompted; two comparable companies raised on a developer-productivity positioning in the prior four quarters.
• Assumptions: That the investors on our list have a thesis for developer tooling, which we have not verified for all of them; that the cost story remains usable as a secondary slide.
• Revisit trigger: If more than a third of first calls open with a spend question, switch the order.

The value of writing this down is that the second decision, the target list, flows directly from it. If the narrative is internal tools, then investors with a developer-tooling thesis go to the top of the list. That is exactly the fit test venture investors apply: does this company match my thesis, my stage and my geography per this VC's account of deck screening.

Consider the alternative outcome. Six weeks in, nobody asks about hiring. Had you written no entry, you would now argue about whether the narrative was ever right. With the entry, you check the trigger, see it fired, and rewrite with a clear record of why.

Target lists fail in a predictable way: they grow, they get shared, and they lose their ranking. A log entry fixes the ranking logic before the list exists.

• Decision: Cap the first wave at 30 investors, ranked by thesis fit, then by warm-path strength, then by check size.
• Options: (A) 30 ranked, (B) 150 unranked, (C) 60 split into three waves of 20.
• Evidence: Five portfolio companies of the target funds that matched our sector; our CRM shows warm paths into 11 of the first 30; average first-response time from warm introductions was nine days in our last raise.
• Assumptions: That a ranked list of 30 produces more meetings than an unranked 150, because preparation time per investor stays constant.
• Revisit trigger: If fewer than eight of the first 30 convert to a first meeting within three weeks, the ranking criteria are wrong and we re-rank.

The evidence matters more than the number. A claim like "investor X funds our category" should point to a portfolio page, a public thesis statement, or a direct conversation. The market-size and traction slides get read closely by investors, so the evidence in your narrative and target entries should be the same numbers you put on those slides as J.P. Morgan's startup banking guidance sets out.

The log is not a parallel document. It should sit underneath the deck and the financial model as the reasoning layer.

When you write the financial projections slide, whether you include one at all is itself a decision worth logging. One advisory firm that has reviewed several hundred decks argues that pre-seed and seed pitches are usually better off skipping the projections slide unless the investor asks or traction makes the projection a story extension per Waveup's analysis. Whatever you decide, the entry should say which rule you applied and what would make you reverse it.

The same applies to structure choices. If you decide to raise a fixed amount with a target dilution band, the entry should record the alternatives (smaller round at a higher price, larger round at a lower one) and the evidence (runway math, hiring plan, comparable rounds). Financial projections in real offering documents carry explicit disclaimers about assumptions and forward-looking risk, which is a useful reminder that your own assumptions deserve the same honesty as in this SEC-filed forecast.

A simple rule keeps the three documents aligned: if a number appears on a slide, the entry that justified it should be findable in under a minute. If you cannot find it, the number is unsupported.

If the point of the log is that a model can review the reasoning later, the format matters as much as the content. Models are good at comparing structured fields and bad at reading between the lines of free prose. Three habits make the difference.

Use fixed field names. Always "Evidence used," never sometimes "Sources" and sometimes "Data." Consistency lets a reviewer pull every entry's evidence into one view.

One claim per bullet. "Seventeen of twenty-two calls mentioned hiring, and two comparables raised on developer tooling" is two bullets, not one, because they can be true or false independently.

Separate fact from belief. Evidence bullets describe things that happened. Assumption bullets describe things you expect. Mixing them is the most common way a log becomes unusable, because a reviewer cannot tell what was checked.

When you review the log later, ask the model three questions: which assumptions were tested and how, which entries have revisit triggers that have fired, and which decisions rest on the thinnest evidence. That is a much more useful exercise than asking it to summarize the raise. General guidance on decision records makes the same point: the rationale and the alternatives considered are the parts worth keeping, not the description of the outcome per monday.com.

If you want the review to run across many entries or many models, Quanta Inference puts text, embedding and other model types behind one OpenAI-compatible API key, which keeps a review pipeline simple as the log grows: https://quantaintelligence.ai/inference

The first row is the one that quietly ruins the whole exercise. A log written retrospectively records the story you now prefer, not the reasoning you actually used, and a model reviewing it will confirm your hindsight rather than test it.