Platform teams accumulate requests in the least useful possible shape: a direct message that says a deployment is blocked, an office-hours question about an unusual build, a ticket asking for "one small permission," or a roadmap item with no evidence that anyone will use it. Each might be important. None is yet enough information to decide what should happen next.

The point of intake triage is not to make people complete a form before they can get help. It is to make the next decision visible. Is this a supported-path question, a production incident, a temporary exception, a discovery problem, or a piece of work that needs an explicit capacity decision? Those paths have different owners, evidence requirements, and acceptable response times.

When they share one queue, the platform team becomes an accidental combination of help desk, incident commander, policy approver, product manager, and implementation team. The queue grows; the promises become private; and the requester has no reliable idea what they are waiting for. A good triage system does not solve every request at intake. It makes the responsible next move hard to misunderstand.

Start with the requester's outcome, not the proposed fix

"Give us production access" and "add a bypass flag" are often reasonable attempts to describe a real constraint. They are not necessarily the problem to solve. Start with a short record that separates the outcome from the requested mechanism:

• What is the team trying to accomplish, and by when?
• Which supported path did it try, and where did that path fail?
• What service, repository, data boundary, or delivery workflow is affected?
• Is something unavailable now, or is the request for a capability the platform does not currently promise?
• What evidence is available: errors, a reproducible example, frequency, user impact, or a known policy constraint?
• Who owns the affected product or service, and who can make the next decision?

This takes less time than rediscovering the same facts through five chat replies. It also gives the requester a fairer answer. "We cannot do that" is a dead end. "The supported workflow does not handle this migration; the service owner and platform product owner need to decide whether a time-bounded exception or a funded capability is appropriate" describes a path forward.

Do not demand perfect evidence before giving routine help. A developer who cannot find the documented build command may need a two-minute answer. The record gets more detailed as the cost, risk, or scope rises.

Route by the next decision

The categories below are deliberately operational. They tell the team what to do next instead of merely labeling the ticket.

The distinction matters most under pressure. An incident should not wait for a weekly product review. A request for a new integration should not be smuggled through an incident channel because the requester has a deadline. An exception can be the right response, but it should name an approver, scope, expiry, and follow-up rather than silently becoming permanent access.

The Exception Backlog Is a Developer Platform Roadmap goes deeper on what repeated workarounds can reveal. Triage is the earlier step: it keeps a single unusual request from being mistaken for either a roadmap commitment or a reason to refuse useful help.

Make a small record that survives the conversation

The intake artifact can be an issue template, a service-management form, or a structured note created by the host after office hours. Its format matters less than the fields that prevent follow-up work from disappearing into memory:

Outcome needed:
Supported path attempted:
Observed constraint or failure:
Urgency and impact:
Risk or policy boundary:
Evidence and reproduction:
Named next decision:
Decision owner and review date:

That last pair is the test. "Platform will investigate" is not a next decision. "The release owner decides whether to accept a one-release exception by Friday" is. "The platform product manager will review three similar migration examples at next planning" is. A request can be valid even when the answer is no; it still deserves a visible owner and rationale.

Avoid assigning a false precision score. Teams often build a five-by-five matrix, add a spreadsheet, and discover that people still cannot tell whether a blocked deploy is an incident. Use simple terms—low, medium, high; one-time or recurring; supported or unsupported—until the real decisions prove that more detail changes behavior.

Protect the supported path from the exception queue

The fastest way to make a platform feel hostile is to force every ordinary question through a project-intake process. The fastest way to make it fragile is to let every unusual request become a private favor. Triage has to preserve both sides.

For supported work, make the answer easy to find and improve the material when the question repeats. A documented command, a working example, or a short office-hours answer can solve a lot of friction without a roadmap project. How To Keep Developer Platform Office Hours From Becoming Unplanned Work explains the useful boundary: a session can clarify and route work without quietly accepting its implementation.

For nonstandard work, capture the user outcome before arguing about the mechanism. A team that requests a manual deployment may really need a supported rollback path. A team that requests broad credentials may really need one diagnostic field. A team that requests a custom build flag may be uncovering a missing extension point. The smallest responsible response might be documentation, a guarded self-service tool, a design review, or a decision to keep the boundary unsupported. It is rarely "make the request disappear."

Review patterns, not the loudest queue

Triage records become useful only if someone reviews the aggregate. Once a week or every planning cycle, look for questions that repeat:

• Which supported-path questions keep needing a human explanation?
• Which exceptions are reaching their expiry without a durable decision?
• Which workarounds are costing multiple teams time or creating unsafe steps?
• Which requests are being declined for the same missing ownership or policy reason?
• Which items have no next decision because the actual decision owner is unclear?

This is not popularity-based roadmap planning. A frequent low-risk question may need better documentation. One rare exception that bypasses a production safety control may deserve immediate investment. The point is to compare actual workflows, costs, and risks rather than a pile of proposed fixes.

Make the Safe Development Path the Easy One sets the complementary standard. A healthy platform does not merely route the same exception forever; it uses reliable evidence to make normal work quicker, clearer, and safer.

A useful triage outcome is a promise you can keep

The goal is not to impress requesters with a process diagram. It is to end an intake conversation with an honest, useful statement: here is the supported path; this is an incident; this exception awaits this decision; this request is being explored with these examples; or this work requires a capacity commitment we have not yet made.

That level of clarity protects platform capacity and respects the person asking for help. It gives an engineer a next action, gives a decision owner a visible responsibility, and gives the organization a record of where its platform is failing to meet real work. That is much more valuable than a queue that merely gets longer in an orderly way.

For more practical engineering judgment, visit Slaptijack.