Advisors & Portfolio Support
How to Build a Portfolio Company Fundraising Intake
Collect just enough founder-approved context to route fundraising support, identify missing evidence and agree on a useful next return.
What you will learn
- Design intake around a specific support request
- Separate founder-approved facts from assumptions and unknowns
- Route incomplete or specialist requests without collecting unnecessary data
A portfolio-company fundraising intake should produce an actionable support brief, not a large database of sensitive facts. Ask what the founder needs, what evidence is ready, who can approve sharing and what useful return the support team can realistically provide. Collect only the context required to route that request.
This guide is for VC platform and accelerator operators receiving requests. The founder still owns the raise and the company's positioning. Start with the broader portfolio support program guide if you have not defined the services you offer.
1. Define what intake will enable
Choose the service decision first: materials review, research feedback, office hours, a specialist referral or introduction readiness. If the team does not offer a service, explain that before collecting details. A founder should not disclose a full data room merely to learn that help is unavailable.
State who can see the request, how it will be used and how the founder can correct it. Keep the operating queue separate from permission to circulate fundraising materials. An internal support request is not a public fundraising announcement.
NIST's least-privilege principle supports limiting access to a task's needs. Use restricted access for sensitive evidence and keep the shared routing record brief.
2. Ask questions that change the next action
Minimum useful fundraising-support intake
| Question | Why it is needed | Avoid |
|---|---|---|
| What specific job needs help? | Chooses a service and owner | “Help us fundraise” with no bottleneck |
| What is the company's current context? | Explains business, stage and relevant market | Long background that does not affect support |
| What timing matters and why? | Distinguishes a real constraint from a preference | Unverified urgency |
| What approved evidence is ready? | Enables the requested review | Unrestricted data-room access by default |
| What may be shared, with whom? | Preserves founder control | Assuming internal access permits external forwarding |
| What would a useful return look like? | Defines completion | A guarantee of investment |
Use branching questions. If the request is a deck review, ask for a reviewable deck and the question to resolve. If it is introduction preparation, ask for approved positioning and a fit rationale, then use the dedicated readiness process. If it concerns an agreement or tax issue, route to qualified help without asking general operators to decide it.
3. Give every submission a clear disposition
- Ready for support: The job, evidence, permission and expected return are sufficient. Assign an owner and confirm realistic timing.
- Missing an input: Ask for the one missing fact or artifact that prevents action. Avoid a generic request for “more information.”
- Needs specialist review: Explain the boundary and the appropriate type of reviewer. Do not make a substantive professional judgment while routing.
- Outside current scope or capacity: Say so clearly and offer a useful next route if one exists. Do not leave the request looking active indefinitely.
Let the founder confirm your summary before the team acts on their behalf. A paraphrase can unintentionally change the business, urgency or ask. Save the confirmed version and keep corrections attributable.
4. Worked example: turn a broad request into a bounded review
Illustrative example: Harbor Sensor asks its investor's platform team to “help with our next round.” The team does not immediately circulate the deck. It asks which bottleneck is most urgent. The founder says investors are misunderstanding the customer, and the next meeting is in nine days.
The intake narrows to a narrative review. Harbor supplies an approved deck, a current customer-definition note and the question: “Can a reader explain who uses the product and who pays?” The founder permits access by the two assigned reviewers, not other portfolio companies or external investors.
Completed intake receipt
Company: Harbor Sensor, fictional.
Job: Clarify the user/payer story before the next meeting.
Return: Annotated opening plus three source-linked corrections.
Evidence: Deck v 8 and customer-definition note v 2.
Timing: Review in five days, before the meeting.
Sharing: Two named internal reviewers only.
Founder confirmation: Scope and summary confirmed.
Disposition: Ready for narrative support, not introduction outreach.
Owner: Platform reviewer.
Completion: Founder receives and evaluates the annotated return.If the deck were unavailable, the disposition would be missing input, not ready. If the founder instead asked whether an offering exemption applied, the route would be qualified counsel, not a narrative clinic. The same short intake can prevent a mismatch without becoming a legal assessment.
5. Copy the founder-approved support brief
Requesting company / founder owner:
Specific job:
Why now / actual deadline:
Relevant business context:
Approved evidence / version / owner:
Unknowns:
Requested service:
Useful return and completion event:
Internal access:
External sharing permission, if any:
Founder confirms this summary:
Disposition / reason:
Support owner / next review:Quality check
- Remove questions that do not affect routing or the service.
- Do not treat a founder's silence as permission to share.
- Do not require confidential detail before establishing the service need.
- Give incomplete requests a specific next input and review point.
Completion check: Another operator can route the request without guessing the founder's ask, inventing permission or promising a financing outcome. Use the support-prioritization guide when several ready requests compete for capacity.