How to Prioritize Portfolio Company Support Requests

Prioritize portfolio support by checking whether a request is actionable, what happens if it waits and how much capacity it requires. Then make the queue decision visible. Do not let the loudest founder, the biggest company or a vague “urgent” label silently consume the whole team's time.

This is service allocation, not investment selection. Use the founder-approved intake brief as input. Keep legal, security or other specialist escalations on the appropriate route rather than forcing them into a generic score.

1. Start with the service capacity you actually have

List named staff hours or service slots after existing commitments. Reserve some space for genuinely unexpected work if your team needs it. Do not assign 100% of nominal working hours to direct support while ignoring preparation, coordination and follow-through.

Estimate effort in a consistent unit. A one-hour call may require another hour of preparation and notes. A deep review may require a specialist who is not available. Record those dependencies rather than pretending every request can be served by any team member.

Techstars' mentor FAQ emphasizes making availability and commitments explicit. Apply that principle to your own queue; the allocation rules below are an original example, not a Techstars policy.

2. Put requests into the correct lane before ranking them

• Ready: The founder's job, evidence and permissions are sufficient.
• Waiting on input: A named missing artifact prevents useful work. Ask for it and retain a review date.
• Specialist route: Appropriate professional judgment or security handling is needed.
• Outside scope: The program does not provide the requested service.

Readiness is not a moral judgment about a founder. Help them understand the next input. A request that arrives fully polished should not always beat a high-impact request from someone who needs a small amount of help framing the problem.

3. Use an explainable comparison, not a magic score

For ready requests, compare the consequence of delay, relevance to the founder's current milestone, time sensitivity and effort. Decide whether the service could remove the actual blocker. A deadline matters only if doing the work by then changes something useful.

Use tie-breaks you can explain, such as the earliest genuine deadline or time already waiting. Review who repeatedly receives help and who falls out of the queue. An override may be justified, but write its reason and effect on other commitments.

Questions for a queue review

Factor	Ask	Do not assume
Consequence	What specific work is blocked?	Every investor meeting is equally consequential
Timing	What date changes the usefulness?	“ASAP” establishes a deadline
Readiness	Can the assigned person act now?	Missing permission can be solved later
Effort	What total preparation and follow-through is needed?	The call length is the entire cost
Fair access	Who has waited or been repeatedly displaced?	Service allocation should follow company publicity

4. Worked example: allocate 12 support hours

Illustrative example: A small platform team has 12 hours available this week, including a two-hour reserve. Ten hours can be assigned now. Four requests arrive.

Weekly support queue

Request	Effort	Decision and reason
Harbor: narrative review before a meeting in six days	4 hours	Assign; materials and permissions ready
Juniper: customer-reference preparation in eight days	3 hours	Assign; removes a specific diligence blocker
Delta: general investor list with no target criteria	Estimated 6 hours	Waiting on criteria; a 30-minute scoping call is assigned
Orbit: hiring-role feedback, flexible timing	2 hours	Assign; owner available and request ready

The allocation is 4 +3 +0.5 +2 =9.5 hours. It leaves 0.5 of the ten planned hours and preserves the two-hour reserve. Delta's full research assignment is not counted as completed or scheduled. Its brief must be confirmed before another allocation decision.

If a genuinely urgent issue uses the reserve, record the service delivered and revisit next week's capacity. If it displaces another promise, tell that founder directly and provide a new expectation. Do not hide missed commitments behind a revised queue.

5. Copy the prioritization record

Week / named available capacity:
Existing commitments and reserve:
Request / founder job / deadline:
Readiness and missing input:
Consequence of waiting:
Estimated total effort and required skills:
Time already waiting / relevant prior support:
Assign / scope / wait / refer / decline:
Reason and override, if any:
Owner / promised return / date:
Founder informed:
Revisit trigger and actual effort:

When the queue fails

• Everything is urgent: Require a specific consequence and date.
• The same founders receive all support: Review allocation patterns and remove avoidable intake barriers.
• Estimates are consistently wrong: Record actual effort and include preparation next time.
• Waiting requests disappear: Retain owner, missing input and review trigger.

Completion check: The queue fits actual capacity, every decision has a reason and founders know what happens next. A transparent “not yet” is more useful than an impossible promise.