Skip to content

Intake Portal

Interface — instantiates Net-Additive Contribution Intake

Gives every well-intended offer a single standard front door, so nothing reaches the team by side channel and the total volume of incoming help becomes visible in one place.

The Intake Portal is the single standard boundary that every offer of help — labor, code, data, goods, access, ideas — must enter through. Its defining move is not screening or sorting but channeling: it collapses a dozen informal ways of reaching the team (a hallway ask, a DM to whoever seems friendly, an email to a personal address) into one front door, and in doing so it does two things nothing else can. It stops offers from landing directly on operational staff as untracked side-work, and — because everything now funnels through one place — it makes the aggregate of incoming demand visible for the first time. It is a channel, not a filter: the portal decides where offers arrive, not whether any of them are worth taking.

Example

A mid-sized open-source project is drowning in help. People propose features in the issue tracker, in the chat server, in replies to the maintainers' personal social accounts, and in surprise pull requests that assume they'll be merged. No one can say how much is coming in, and every maintainer is quietly fielding a private queue. The project stands up an Intake Portal: a single "Propose a contribution" entry that every offer — bug fix, feature, doc, sponsorship — is asked to go through, with a clear notice that proposals sent by other routes will be redirected there rather than actioned.

Within a quarter two things change. Maintainers stop discovering half-built features in their DMs, because the portal is now the only door that leads anywhere. And for the first time the project can see its own demand: ≈40 contribution offers a week, two-thirds of them small doc fixes. That number — invisible while everything arrived by side channel — is what lets them realize the real bottleneck isn't code, it's review capacity, and to plan accordingly.

How it works

What distinguishes the portal from a generic form or queue is that it is the boundary itself:

  • One declared front door. A single, advertised place offers must enter, so there is no legitimate "other way in."
  • Side-channel closure. Offers arriving by back channels are politely turned back to the door rather than quietly actioned; the portal's value collapses the moment exceptions become routine.
  • Demand made visible. Because all offers pass one point, their rate, mix, and trend can be counted — the first honest read on how much help is actually arriving.

The portal deliberately stops there. It captures the offer at the boundary and hands it onward; the structured questions, the sorting, and the judgment all belong to downstream mechanisms.

Tuning parameters

  • Door breadth — whether the portal accepts every kind of offer or only certain classes. A wide door catches everything but mixes incomparable offers; a narrow door pre-sorts at the cost of turning some contributors away at the threshold.
  • Entry friction — how much a contributor must do to get through the door. More friction deters low-effort noise but also deters good, busy contributors; too little and the portal floods.
  • Visibility — public and self-serve versus private and mediated. A public door invites volume and self-selection; a private one controls exposure but re-creates the gatekeeper the portal was meant to replace.
  • Side-channel strictness — how firmly back-channel offers are redirected. Strict enforcement preserves the single-door benefit but can feel bureaucratic; lax enforcement quietly restores the chaos.

When it helps, and when it misleads

Its strength is that it ends the two failures of informal intake at once: offers stop ambushing individual staff, and demand stops being invisible. A single door is also what makes every later step — sorting, screening, refusing — possible, because there is now one stream to act on.

It misleads when the door is treated as capacity. A portal that accepts everything smoothly can create the impression the system is absorbing everything smoothly, when in fact it is just accumulating a well-organized backlog — the queue is visible but no shorter. Its other failure mode is desertion: if the door is too rigid or too slow, contributors route around it and the side channels quietly reopen as shadow processes.[1] The discipline that guards against both is to pair the portal with an explicit capacity read and to keep the door light enough that using it beats going around it.

How it implements the components

The Intake Portal realizes the boundary-and-visibility components — the ones a channel can fill:

  • intake_boundary — it is the single standard boundary offers must cross; the front door itself.
  • bypass_and_side_channel_monitor — enforcing one door means watching for and turning back offers that try to arrive another way.
  • contribution_demand_signal — funneling all offers through one point is what makes the rate and mix of incoming help countable.

It does not turn an offer into structured, comparable data or provide the self-service questionnaire — that is Pre-Screening Form — and it does not classify or route what arrives, which is Automated Classification and Routing.

Notes

The portal is a channel, not a gate. It standardizes where offers arrive and makes them countable, but it says nothing about whether any given offer should be accepted — that judgment lives entirely downstream. Confusing "we have a front door" with "we have a way to say no" is the most common way a portal gives a false sense of control.

References

[1] Shadow IT / shadow processes — the well-documented tendency for people to route work around an official channel that is too slow or rigid, recreating the very informality the channel was meant to eliminate. The portal's single-door benefit only holds while using the door is easier than going around it. ↩