Service Desk Portal Best Practices in the AI Era
The Service Desk portal is undergoing a fundamental shift. For years, the industry standard was the "Service Catalog"—a dense, hierarchical list of forms designed to force users into rigid data structures. In the AI era, this model is not just outdated; it is a friction point that prevents scaling.
The central thesis is simple: the portal should not be a library of forms, but a conversation with an architect.
The Fall of the Static Catalog
Most companies use a fraction of what Jira Service Management (JSM) can deliver because they treat the portal as a technical tool catalog. They build hundreds of request types, each with its own set of custom fields, and expect the user to navigate the complexity.
The problem is that users don't want to be Jira experts. They want a laptop, a permission, or a fix. When we force them to choose between "Laptop Provisioning" and "Laptop Refresh," we are offloading our organizational complexity onto them.
In the AI era, the architect's value is translating that complexity into a simple, governable model. This means moving away from the "Omni-channel" mess toward an "Omni-intelligent" strategy.
Architecture over Administration
During a recent migration project from ServiceNow to JSM, a recurring debate surfaced: should we show the full catalog or hide it behind a single, intelligent entry point?
The "Builder" mindset wants to show everything. It’s easier to build a form than to architect a flow. But the "Architect" understands that a visible catalog is a fallback, not the primary interface.
1. The "Invisible" Catalog The most mature operations I design today use a "headless" catalog approach. The forms exist—fully detailed with all the technical fields required for automation—but they are not the primary way a user interacts with the service. Instead, an AI agent (like Atlassian Rovo) acts as the triage layer.
2. Triage vs. Execution We must separate the intake from the fulfillment. A user should be able to say, "I need to swap my laptop because it's slow." The AI doesn't just open a ticket; it consults the CMDB, sees the device is four years old, and identifies this as a "Laptop Refresh" rather than a "Repair." It then maps the conversation to the correct, hidden form.
3. The Fallback Principle Total reliance on AI is a risk. Architecture is what prevents companies from scaling chaos. We keep a generic "I need something else" form as a safety net, but we treat its usage as a metric of failure for our AI's intent recognition.
Concrete Best Practices for the AI Era
If you are still designing portals based on 2019 principles, you are building technical debt. Here is how we are architecting modern service desks:
Eliminate Redundant Questions: If the data exists in your CMDB or identity provider (like Okta), do not ask for it. The AI should pull context, not request it.
Dynamic Playbooks over Rigid Workflows: Instead of 50 different workflows, use a unified "Triage" status. The AI reads the internal documentation, builds a dynamic plan, and executes the steps—only involving a human for high-risk approvals or physical tasks.
Bilingual Register: The portal must speak "User" (natural language) and "System" (structured data). The AI is the translator.
Governance as a Guardrail: Block direct CMDB edits. Every change must be the result of a governed workflow, whether initiated by a human or an agent. This ensures that "Auto" fields remain the source of truth.
The Architect’s Closing
Jira is flexible; that is both its power and its risk. In the AI era, execution is becoming a commodity. Anyone can generate a response or move a ticket. The real competitive advantage lies in the architecture—the underlying structure that ensures the AI is asking the right questions and updating the right systems.
The architect does not complicate the company; the company is already complex. Our job is to organize that complexity so the user never has to see it.
If this connects with where your service operation is right now, I can open space for a technical conversation about how we are implementing these "headless" service architectures.