IT teams drowning in routine requests is a familiar story. Developers waiting days for a new environment. Security reviews bottlenecking every change. The same provisioning tasks repeated manually, consuming time that could go toward more valuable work.
Self-service infrastructure portals promise to fix this. Give users the ability to provision what they need within guardrails, and the backlog disappears.
Except it often doesn’t. Many self-service initiatives fail—not because the technology doesn’t work, but because the portal doesn’t match how people actually need to work.
The Adoption Problem
We’ve seen organizations build technically sophisticated portals that nobody uses. The portal exists, it works correctly, it automates real workflows—but requests still come through email or tickets because that’s what people know, and the portal creates just enough friction to make the old way more appealing.
The pattern is predictable: IT builds what they think users need based on their own perspective of the problem. They launch it, announce it, maybe run a training session. Then they wait for adoption that never comes. Users try it once, hit friction they didn’t expect—a confusing form, a required field they don’t know how to fill, a workflow that doesn’t match their mental model—and they go back to whatever worked before. Email to the sysadmin. A ticket in the queue. The familiar path of least resistance.
The portal becomes shelfware: technically functional, officially available, and practically unused. IT points to it as evidence of progress; users work around it as evidence of how IT doesn’t understand their needs.
What Makes the Difference
Portals that succeed share characteristics that failed ones lack. These aren’t technical features—they’re design philosophies that shape every decision about how the portal works.
They start with actual workflows. Before building anything, understand how requests currently flow. Shadow the people who make requests and the people who fulfill them. What information do users actually provide when they send an email or submit a ticket? What approvals are genuinely needed for governance versus bureaucratic habit accumulated over years? Where does work get stuck waiting for responses or clarifications?
The goal isn’t to automate the existing process—it’s to design a better one. Often the current process has unnecessary steps, asks for information that isn’t really needed, or creates delays that serve no purpose. But you can’t improve what you don’t understand, and you can’t understand the process by looking at documentation that describes how it’s supposed to work rather than how it actually works.
They’re genuinely easier than the alternative. If submitting a request through the portal takes longer than sending an email, people will send emails. The bar is low but non-negotiable: be faster and simpler than whatever users currently do. That’s the only way to overcome the inertia of existing habits.
This often means aggressive simplification. Fewer fields—only ask for what you genuinely need. Smarter defaults that pre-populate based on who’s requesting and what they typically need. Eliminating steps that don’t add value, even if those steps exist in the current process. Every field, every click, every decision point is a potential reason for users to abandon the portal and go back to email.
They handle the 80%, not the 100%. Trying to cover every possible request creates complexity that undermines the common cases. A portal that handles everything handles nothing well—every form becomes a maze of conditional fields, every workflow becomes a decision tree that confuses users who just want the simple case.
Build for the requests that happen constantly: the development environment that gets provisioned weekly, the database that teams request monthly, the storage bucket that’s needed for every new project. Handle edge cases through a different path—maybe those still go through a ticket queue, but now the ticket queue is manageable because it’s only handling the genuinely unusual requests.
They enforce without obstructing. Guardrails matter—you can’t let anyone provision anything without oversight in a production environment. Security reviews exist for good reasons. Compliance requirements are real. But controls should be invisible when they’re not triggered. The user requesting a standard development environment shouldn’t feel the weight of controls designed for production access. The developer creating a test database shouldn’t go through the same approval workflow as someone requesting access to customer data.
Good portals implement risk-based controls: simple requests flow through with minimal friction; risky requests trigger appropriate review. This requires understanding what’s actually risky versus what’s just treated as risky because that’s how it’s always been done.
The Trust Factor
Self-service requires IT to give up some control, and that’s genuinely uncomfortable for teams that have been gatekeepers for their entire existence. There’s always a reason why someone shouldn’t be able to do something without oversight. What if they make a mistake? What if they don’t understand the implications? What if they create a security vulnerability or blow through the budget?
These concerns aren’t irrational—they’re based on real incidents that happened in the past. But the alternative—IT as a bottleneck for every routine request—doesn’t scale. As organizations grow and development velocity increases, the ticket queue becomes a constraint that slows everyone down. Developers wait days for resources they need today. Projects miss deadlines because provisioning takes too long. Shadow IT emerges as teams find their own ways to get what they need without going through official channels.
The question isn’t whether to trust users, but how to make that trust safe through automation. Compliance checks that run automatically can verify that resources meet security requirements without requiring a human to review each request. Cost controls that prevent runaway spending—budget limits, approval triggers for expensive resources—protect the organization without blocking standard requests. Audit trails that capture who provisioned what, when, and with what justification provide accountability without creating friction.
The goal is making it easier to do the right thing than the wrong thing. When the self-service portal is the path of least resistance, and that path automatically enforces the guardrails that matter, you get both velocity and governance.
Starting Small
The temptation is to build a comprehensive portal that handles everything—a single system that covers every type of infrastructure request, every approval workflow, every edge case. Resist this temptation. Comprehensive portals take a long time to build, often miss the mark because they’re designed in isolation from real use, and create a high-stakes launch where everything has to work or nothing does.
Start with one or two high-volume request types. What do developers request most often? Development environments? Databases? Storage buckets? Pick the request type that’s both high-volume and relatively straightforward—something that will demonstrate value quickly without requiring complex workflow logic.
Get those working well. Obsess over the user experience. Watch people use the portal and fix the friction points. Make it genuinely easier than the alternative. Prove that users will actually use self-service when it’s done right.
Then expand deliberately. Each addition is a chance to learn: what do users actually need that the current portal doesn’t provide? Where do they get confused by the interface or the process? What did we assume wrong about how requests work? These learnings should influence not just the new features but refinements to the existing ones.
Self-service infrastructure works when it genuinely serves users instead of just shifting work from IT to everyone else. Building a portal that IT likes but users avoid isn’t self-service—it’s self-deception. True self-service requires understanding users deeply, simplifying ruthlessly even when that means challenging existing processes, and building trust through guardrails that protect the organization without obstructing the people who need to get work done.