AI transformation doesn’t just start with a roadmap

Most companies frame AI transformation as it begins with something formal and top-down. At Homebase, it started smaller, with a hackathon demo that turned into a rough prototype, built by a team that chose to start before anyone told them to.

There was no formal kickoff or directive from leadership. Just a prototype, a point of view, and a sense that the People team could do more than wait to be told what to implement. Over time, that shift turned into something bigger: a company-wide approach to AI grounded in experience design, not just efficiency.

It all started with a demo

There’s a pattern you see across a lot of organizations. HR teams waiting for the business to define the problem. Waiting for IT to greenlight tools. Waiting for the right moment to act.

At Homebase, instead of waiting, the team built something first, and that shifted the dynamic. The People team just started with a simple idea: what if we built something and saw where it went? They were showing what was possible, so the conversation moved from abstract planning to something concrete.

That early prototype didn’t need to be complete. It just needed to exist to give the work momentum, and it created a different kind of credibility — one that comes from building, not proposing. That shift from “this could work” to “this is working” became a growth accelerator for everything that followed.

HR as internal customer support

As the work evolved, the focus moved quickly beyond AI as a technology and toward something more fundamental: the employee experience.

The issue was in how those systems were designed. They were shaped around internal processes and limitations, not around what employees actually needed. That’s how you end up with slow responses, inconsistent answers, and conversations that change depending on who picks up the ticket.

At Homebase, the People team chose to treat that as a design problem. Employees, or “Homies” were reframed as internal customers, and the standard shifted accordingly. 

The help desk was where this shift showed up first. It wasn’t treated like a feature to roll out, but as a chance to rethink what a good internal experience should feel like and to build toward that more deliberately.

Build the foundation before the automation

A lot of teams want to jump straight to agents, but Homebase took a different route. They started with the less visible work that everything else depends on: getting their knowledge base in order. They focused first on document inventory, structuring information, and creating a system that could reliably answer questions.

It may not be the part anyone gets excited about, but it shapes everything that comes after. Without that foundation, automation breaks easily, answers drift, and people stop trusting the system. By investing in the underlying knowledge first, the team created something that could compound in value. Each interaction strengthened the system rather than exposing its limits.

Only after that foundation was in place did automation begin to layer in. The crawl, walk, run approach led to a system that held up better and delivered more consistent results over time.

Ownership changed what the system optimized for

Ownership looked different on this project. In most companies, HR is brought in to advise, help with rollout, and keep things aligned. At Homebase, the People team took the lead.

They set the roadmap, ran the sprints, managed the vendor relationship, and shaped the employee experience end to end. That level of ownership changes how a system comes together. Because the People team led, the system was optimized for the employee: how it feels to ask for help, how quickly you get a response, and whether the experience builds trust.

The decisions about ownership shaped the entire system, from how workflows were designed to how success was measured.

Designing for the full employee lifecycle

Most help desk implementations are built to solve a specific problem like access requests, onboarding tasks, or benefits questions. They work well enough in isolation, but they rarely connect to a broader experience.

From the beginning, Homebase approached this differently. The team thought in terms of the full employee lifecycle from the moment someone accepts an offer, through onboarding, team transitions, and eventually offboarding. Each of those moments carries weight. They shape how someone experiences the company and how they remember it. Treating them as disconnected workflows misses that context.

Designing across the lifecycle meant building something more flexible. A system that could adapt to different moments while still being consistent. It’s not finished, and it’s not meant to be as it’s a living system that evolves alongside the organization.

What good workflows actually feel like

It’s often easier to describe what doesn’t work than what does. A new employee asks a question, submits a ticket, waits days for a partial answer, and then follows up into silence. That pattern is familiar because it’s so common. But it’s not a workflow failure. It’s a design failure.

At Homebase, the standard was different. Every workflow had to pass a simple test: does this make the employee’s experience better, or does it just make internal tracking cleaner?

The difference changes how systems are built. Good workflows meet people where they are, often in Slack rather than a separate portal. They understand context, respond quickly, and know when to escalate to a human without forcing repetition.

Most of the complexity such as routing, approvals, escalation paths still exists. It just stays in the background. From the employee’s perspective, the experience is straightforward.

The best workflows tend to disappear into the experience. You don’t notice them working. You just get what you need.

Moving beyond the efficiency narrative

It’s difficult to talk about AI without defaulting to efficiency. Doing more with less, reducing workload, automating repetitive tasks. Those outcomes matter, but they weren’t the most interesting part of this work.

At Homebase, the focus was on what the system made possible. When policy questions are handled automatically and onboarding friction is reduced, the People team doesn’t just move faster. They get space back. Space to spend time with employees, to design better experiences, and to focus on the parts of the job that actually require human judgment.

There’s a phrase the team uses to describe this: a deletion north star. The work that disappears is what proves the system is maturing. Less repetitive work for the team signals that the system is doing what it was designed to do.

Change requires honesty

Rolling out a system like this usually comes with a structured change plan involving training sessions, documentation, and internal announcements. Those things help for sure, but they can’t drive adoption fast enough.

What made the difference here was a more direct approach. Being clear about what was changing, what might feel uncomfortable, and why the shift was necessary.

The team described it as a combination of disruption and compassion. Naming hard truths while also recognizing the experience of the people going through the change. That balance made the transition feel more grounded and like something the organization was building together.

Slowing down changed how the system was built

One of the more subtle influences on the work came from the partnership itself. There was an initial instinct to move quickly, to solve problems as they came up and keep momentum high.

At certain points, that pace was challenged. It may have slowed down the progress, but improving the quality of decisions was a bigger priority.

Taking time to step back and think about the experience more deliberately led to fewer reactive fixes and more cohesive design. It introduced a more product-oriented way of thinking that prioritizes how the system feels to the end user.

When the model spreads, you know it’s working

The clearest signal that the approach was working came from how the rest of the organization responded.

Other teams started to take notice of not only the system itself, but of how it was built. They began to look to the People team as a model for how to approach similar problems. That kind of pull is hard to manufacture because it comes from the approach resonating beyond the original use case.

At the same time, the system itself improved in more tangible ways. Requests that once disappeared into Slack threads became structured and trackable. The team gained visibility into what was happening, and the system became more effective with each interaction.

Final thoughts

There’s a line that comes up often in this work: People teams don’t just support AI transformation, they lead it.

At Homebase, that wasn’t just something said in principle. It showed up in starting small, building the foundation first, owning the system end-to-end, and designing around the employee experience.

What came out of it isn’t simply a finished product. It’s a system that keeps evolving, shaped continuously by the people it serves and the realities they run into every day.

For teams thinking about where to begin, the takeaway is fairly simple. Not to start with the technology, but to start with the experience and build outward from there.

To see how Ravenna can direct your organization's AI transformation, schedule a demo with us.