Allocating Desks and Cabins Without a Waiting-List Argument

The half nobody writes about

Search for advice on running an incubator and you will find a great deal about selection, mentoring and demo days. You will find almost nothing about who gets which desk.

Which is odd, because if you run a physical incubation centre, space is the thing you get asked about most, argued with about most, and audited on most. It is also the part that most often runs on a whiteboard and a shared sheet long after the rest of the programme has been organised.

Decide the pricing structure before the first allocation

You need a small number of tiers, published, with what each includes. Something like:

Tier	Typically	Includes
Hot desk	Any free desk, no fixed seat	Internet, common areas, meeting-room quota
Fixed desk	A named seat	The above, plus storage and a fixed location
Small cabin	3-5 people	The above, plus a lockable room
Large cabin	6-12 people	The above, plus a larger room
Virtual	No space	Registered address, mail handling, meeting-room quota

Two things matter more than the exact tiers.

Publish what each includes, particularly the meeting-room quota. Most arguments about meeting rooms are really arguments about whether they were included, and a published quota ends them before they start.

Have a virtual tier. Startups that are remote, that have outgrown you, or that only need a registered address will otherwise occupy a desk to keep the association. A virtual tier lets them stay attached to the programme without holding space, which quietly reclaims more desks than any policy on utilisation.

On subsidy

Most incubation centres subsidise heavily, and should. But charge something.

A desk at a nominal monthly rate behaves completely differently from a free desk. People give up a nominal desk when they stop needing it. Nobody gives up a free one, because there is no cost to holding it and there is a cost to admitting they have left. Reclaiming free space is the single hardest administrative task in an incubation centre, and the way to avoid it is not to create it.

Deposits: take one, and write down the conditions

A deposit is not primarily about damage. It is about having a defined moment at the end of the arrangement when both sides have to agree the arrangement has ended.

Write down, at allocation:

• The amount, and that it is a deposit rather than advance rent
• What it can be withheld against - damage, unpaid dues, keys not returned
• How long after vacating it is returned
• Who signs off

The dispute you are avoiding is the one eighteen months later where a founder says the deposit covered the last month's rent and you say it did not. That conversation is decided entirely by what was written at the start.

Write the cabin rule down before anybody asks for one

Cabins are scarce, visible, and the thing teams compare. If you allocate them case by case, you will at some point have two similar teams and no articulable reason why one got a room.

Defensible bases, roughly in order of how well they hold up:

1. Team size. Objective, verifiable, and it maps to the actual constraint.
2. Stage or funding status. Defensible if written down, though it can read as rewarding the already-successful.
3. Programme cohort. Fine if your programme genuinely differentiates.
4. Time in the centre. Defensible but rewards incumbency, which is the opposite of what most centres want.

Whatever you choose, publish it. A rule you can point at converts an argument about fairness into a conversation about facts.

Separate ongoing allocation from time-slot booking

These are two different things and treating them as one causes most operational trouble:

• An allocation is ongoing. A desk, a cabin. It has a rate, a start, a deposit, and a recurring charge.
• A booking is a window. A lab, a meeting room, a piece of equipment, on a day, between times, often needing approval.

Bookings need approval more often than people expect. A lab with one piece of shared equipment, a room that doubles as the interview room during selection week - these need someone to say yes, and the approval needs to be attached to the booking rather than living in a mail thread.

Plan graduation from the beginning

The conversation you will have most often, and the one centres are least prepared for, is asking a company to leave.

It gets easier if it was never a surprise:

• Put a term on every allocation, even a renewable one. A renewal conversation is much easier than an eviction conversation.
• Set the notice period both ways at the start.
• Define what graduation means for space specifically - do they move to virtual, get a grace period, move to commercial rates?
• Review allocations on a schedule rather than when space runs short. Reviewing only under pressure makes every review feel like an accusation.

What to record against every allocation

If you only take one thing from this article, make it this list. These are the fields that come up later:

• Which startup, and which programme or cohort
• Tier, and specific desk or cabin
• Rate, billing frequency, and what it includes
• Deposit amount, date taken, conditions for return
• Start date, term, notice period
• Current status - active, notice given, vacated
• Payment history, and what is outstanding
• Who approved it

A shared spreadsheet holds about the first five of those. The ones it loses are payment history and approval, which are the two an auditor asks about.

The realistic tooling answer

For a centre with a dozen desks and one room, a spreadsheet is genuinely fine and you should not buy software.

It stops being fine at around the point where you have multiple tiers with different rates, deposits you have to return correctly, recurring charges you have to collect, and bookings that need approving. At that point the failure is not that the spreadsheet is wrong - it is that the spreadsheet has no memory of who approved what, and no way to stop two people booking the same lab slot.

If you get to that point, the questions worth asking a vendor are narrow: can it hold different tiers with different rates and deposits, can it take recurring payment and pay out to your own account, can a booking require approval, and does it keep the payment and approval history where an auditor can see it.