The Atlassian Friend #3: Beyond the Portal

[#1]

Reimagining Employee Experience with Jira Service Management, Rovo, and Assets

About this article

This article isn't an implementation guide, nor is it an attempt to predict where Atlassian products are heading. It's the result of spending a lot of time thinking about a problem that kept bothering me while designing Enterprise Service Management solutions.

The architecture I describe here is conceptual. It combines Jira Service Management, Rovo, Assets and Automation, but the products themselves aren't really the point. What interests me is how they could work together to create a better employee experience.

Technology changes quickly. Architecture should evolve with it. Rather than trying to predict the future, I'd rather share the way my own thinking evolved while working on this design.

Introduction

A few months ago I started designing what I thought would be a fairly straightforward preboarding architecture using Jira Service Management.

My objective seemed obvious: improve the onboarding experience for new employees.

But the more time I spent refining the architecture, the more I felt I was solving the wrong problem.

It wasn't that onboarding was broken.

It was that we still tend to design employee experiences around the way our organizations are structured instead of around the people using them.

We create portals for IT, People Operations, Facilities and Security because that's how we think internally.

Employees don't think that way.

When someone accepts a job offer, they're usually asking themselves a much simpler question:

"What do I need to do next?"

The more I kept coming back to that question, the more everything else in the architecture started changing.

I stopped thinking about how employees could better understand our organization.

I started wondering whether the organization should be doing a much better job of understanding the employee instead.

That idea gradually became the foundation for everything else in this architecture.

From Help Center to Employee Experience Hub

At that point I also stopped thinking about the Help Center as just another portal.

I started seeing it as the natural entry point into the employee journey.

Not simply somewhere to submit requests, but somewhere employees could find guidance, knowledge, forms, approvals, tasks and progress without needing to understand how the company is organized behind the scenes.

My goal wasn't to improve navigation.

It was to make navigation far less important.

If the platform understands what an employee is trying to accomplish, most of the complexity can remain behind the scenes while the experience itself becomes much simpler.

Rovo: More Than an AI Assistant

As I continued working on this architecture, I found myself questioning one assumption I'd made from the beginning.

I had been thinking about Rovo as another AI assistant. It could answer questions, search documentation and summarize information, and while all of that is useful, I couldn't shake the feeling that it wasn't the interesting part of the problem.

The more I refined the architecture, the more obvious it became that I wasn't trying to design a better chatbot.

I was trying to create a better employee experience.

Those are two very different objectives.

That realization completely changed the role I imagined for Rovo.

Instead of seeing it as an assistant, I started thinking about it as the employee's Journey Guide—or maybe an even better analogy is a travel companion.

Every journey is easier when someone walks beside you.

Think back to your first days at a new company. Most of us have exactly the same questions: Where do I find this? Who should I contact? Which policy applies? When will my laptop arrive? What should I do next?

What always struck me is that the difficult part usually isn't the question itself. It's knowing where to look.

That's the problem I think AI is uniquely positioned to solve—not by replacing People Operations, managers or IT, but by removing uncertainty.

A good travel companion doesn't just answer questions. They understand where you are, where you're heading and what you've already completed. That context is what allows them to guide you towards the next step.

That's the role I see for Rovo.

The employee shouldn't need to know which form to search for or which department owns a process. They should simply describe what they're trying to achieve.

"I'd like to choose my laptop."

"I don't understand this security policy."

"What should I do today?"

The platform should understand the intent. Everything else becomes orchestration.

Context is what changes everything.

Two employees can ask exactly the same question—"What should I do next?"—and still need completely different answers because they're at different points in their journey.

That's why I don't really think of Rovo as an AI assistant anymore. I think of it as a Journey Guide.

The conversation shouldn't restart every day either. It should continue naturally, remembering what happened yesterday and using that context to guide what happens next.

Knowledge also becomes contextual. Instead of expecting employees to search through articles, policies or forms, the platform should surface the right information when it actually becomes relevant.

The more I explored this idea, the less it felt like an onboarding architecture.

Onboarding simply became the first journey in what I now think of as a much broader Employee Experience architecture.

The Platform Behind the Journey

Up to this point I've focused on the employee experience itself: guidance, context and reducing uncertainty.

But none of that happens on its own.

Every recommendation, every conversation and every next step depends on an architecture working quietly behind the scenes.

One idea kept coming back while I was designing this architecture:

The employee should experience simplicity.

The platform should deal with the complexity.

I've always felt that good architecture works best when people barely notice it's there.

If employees have to think about how the platform is organized, we've probably pushed too much complexity into their experience.

Jira Service Management as the Journey Orchestrator

From this perspective, Jira Service Management stops being just a service desk.

It becomes the orchestration layer for the employee journey.

Employees experience a journey made up of activities. Some require their input. Others trigger work for internal teams. Some simply provide guidance.

The important part is that employees shouldn't need to distinguish between any of those things. They should simply continue their journey while the platform coordinates everything else.

The Journey Generates Work

When an employee completes a step, that single action may generate work for IT, People Operations, Security, Facilities or other teams.

Most of that orchestration should remain invisible.

To the employee it still feels like one continuous experience, even though dozens of automated activities may be happening in the background.

Assets as Operational Context

To me, one of the most interesting roles of Assets is providing operational context.

Yes, it can manage inventory, but I think its value goes much further.

It can represent employees, managers, locations, equipment and even configurable journey templates that allow the platform to evolve without hardcoding every process. 

Respecting Systems of Record

I've never liked architectures that try to centralize everything.

Workday should remain Workday. Okta should remain Okta. Finance systems should continue owning financial information.

Good architecture isn't about moving data into one place. It's about understanding where every piece of information belongs and using it responsibly.

Automation Becomes Orchestration

The more I developed this architecture, the less I saw Automation as a collection of rules.

It became the orchestration engine connecting everything together: creating activities, synchronizing information, invoking APIs, updating Assets and quietly moving the employee journey forward.

Beyond Onboarding

Somewhere along the way I also realized I wasn't really designing an onboarding architecture anymore.

Onboarding simply became the first journey.

The same principles naturally extend to learning, internal mobility, equipment management and many other employee interactions.

Final Thoughts

When I first started this project, I thought I was trying to build a better onboarding solution.

Looking back, I think I was actually trying to answer a much simpler question:

How do we make sure employees never feel lost inside an organization?

If technology quietly removes uncertainty instead of adding complexity, employees won't remember the platform.

They'll remember the experience.

To me, that's what good architecture has always been about.

Antonio Ferruz - The Atlassian Friend