Your platform team is now a ticket queue — every environment, every permission, every new service goes through them. How do you get out of it?

Categorise the queue before automating anything

Take a month of tickets and group them. The distribution is always uneven, and two or three categories are usually most of the volume — typically environment creation, access requests and a specific recurring configuration change.

Automating the largest category first is the highest return, and it is frequently not the one the team finds most interesting.

For each, ask what judgement the ticket applies

The ticket exists because someone checks something: is this sized sensibly, tagged, in the right network, compliant. Self-service works by encoding that judgement into the request path so it is applied automatically and instantly.

The team declares intent at a level above raw resources — "a PostgreSQL database for service X, production, medium" — and the platform expands it into something already tagged, already in the right subnet, already encrypted, already backed up, already sized within a permitted range. The reviewer's checks are not performed; they are unavailable to get wrong.

Keep the residue small and shrinking

Review is then only for what falls outside the bounds. If most requests still need an exception, the bounds are wrong and the queue has not actually moved.

Build the destruction path at the same time

Self-service creation without self-service decommissioning and per-team cost visibility produces an estate that only grows. This is the half that gets deferred and it should not be.

Protect the capacity you free

Otherwise the queue refills. Ring-fence a proportion of the team for building rather than serving, from the start, and hold it — because a platform team that spends all its time on tickets never builds the thing that would end the tickets.