Level 1 to Level 2: The Leap to a Live PSA System

Going from Foundation to Activation is the first leap in the SOMM, and it is the part of this work I love building most.

People ask me which implementation has been my favorite, and I never have a clean answer. It feels a little like asking a parent to name their favorite kid. I have loved so many of them for completely different reasons: the ones where everything clicked, the complicated ones that pushed my thinking, the teams I genuinely looked forward to talking to every week. What ties them together is the same part every single time. Taking a blank slate and turning it into a system that actually works for the business in front of me.

In the Services Operations Maturity Model, this is the leap from Level 1 to Level 2, the move from Foundation to Activation. It is the move to a live PSA system, whether you are coming off spreadsheets or a tool you have outgrown. It is one of the most consequential leaps an organization makes, it is the hardest, and in my experience it is the most worth making.

What you are leaping from

Not everyone starts this leap from the same place, and it is worth being clear about that.

Some organizations are coming off spreadsheets and duct-taped tools, building toward a real system for the first time. Others have outgrown what they have. The system that served them at one size is now holding them back, and the move is about gaining the structure, functionality, and room to scale that their current setup can no longer give them.

The two paths feel different from the inside. One crowd is meeting real structure for the first time. The other already lives with structure and is after expansion and a system that finally keeps up. What they share is the destination: clean data, consistent processes, and reporting they can trust.

These two starting points split fairly evenly in my work. I see about as many migrations from an outgrown system as I do teams coming off spreadsheets.

To keep this concrete, here is one from the spreadsheet side. I worked with a client whose setup was a familiar one: spreadsheets, a few smaller systems, Excel-based reporting that one person had been holding together by hand for years, and a third-party tool handling time entry. On the surface it worked. Underneath, it took constant manual effort to keep standing.

What made that engagement go well had very little to do with the software and almost everything to do with how the client showed up. They had strong internal communication. Finance and operations respected each other and actually talked to each other, which is rarer than it should be. Most importantly, they were aligned on what they needed out of their reporting before we configured a single thing.

I would take a clear picture of the end goal over a tidy list of generic requirements every time.

That alignment is worth more than people realize. When a client knows the end result they are after, I can get creative about how to get them there. I can guide instead of guess.

Here is where experience earns its keep, though. Most clients cannot hand you that clarity in clean sentences. They give you half-formed thoughts, high-level wishes, the way they do things today described in a hurry between meetings. A good consultant listens to those half-baked sentences and reads between the lines. I hear "we need to be able to see X," and I already know what we have to build to get them there. That translation, from what a client can articulate to what the system needs to do, is most of the job.

Fitting the pieces together

Almost anyone can get a PSA into some usable state. Getting it to work for your business, with your requirements and your way of operating, is a different thing entirely. Every organization is chasing the same destination, and every one gets there a little differently. That is why a setup that dazzles in a demo can still be wrong for you. The build has to fit the business, not the other way around.

My whole approach comes down to one idea: uncomplicate your business process. A new system is your chance to do exactly that.

Most teams want to replicate what they did before, and I understand the instinct. Change is hard. But rebuilding your old workarounds in a new tool just buys you a more expensive version of the same mess. The better move is to find the simpler version underneath how you work today, and to ask "why do we do it this way" before you ask the system to do it for you.

One last piece, and it is the one to protect: a good build does not make you dependent on whoever built it, it makes you the owner. The right person beside you is invested in handing you the keys, not holding them. Judge anyone you bring in on whether they are building your understanding along with your system. That is the difference between a system you run and one that runs you.

What nobody plans for in the first few weeks

Now comes the part nobody puts in the brochure. The leap is worth making, and it still asks more of you than most teams expect. Three things surprise almost everyone.

Preparing your legacy data takes longer than you think. This is the one clients consistently underestimate. Moving data into a new system is not a copy-and-paste exercise, it is a cleansing exercise. Data that has lived in spreadsheets for years carries inconsistencies, gaps, and errors nobody noticed because nothing ever forced them to. Getting it trustworthy before it goes in is real work, and it is work worth doing right, because every report you run later sits on top of it.

Structure is an adjustment, and for some teams a hard one. A new PSA system brings structure, and structure is mostly a good thing. For organizations that have lived in spreadsheets, though, it can feel foreign at first. In a spreadsheet you can finagle a number however you want with no real consequence. In a proper system you cannot. Everything has a purpose and a deliberateness behind it, and a change in one place has implications in another. For some teams that is a relief. For others it is a genuine adjustment, and the way through is to keep pointing them back at the reporting they told me they wanted, and to show them how the structure is exactly what makes those results possible.

You will not have a full set of data on day one. Plan for this one. In the first weeks you will have some data, not a complete picture. That is normal and it is not a reason to wait. You can start running reports and monitoring progress immediately, as long as you are clear about what the data you do have can and cannot tell you yet. The comprehensive picture comes with time. The habit of using the system starts now.

Go-live is the icing on the cake

By the time go-live arrives, the hard part is largely behind you. It is the moment everything has been building toward, and seeing a finished system that meets the client's needs, ready to use on both sides, is one of the most satisfying parts of this work.

In the days around go-live I tell clients what to expect. I give them a heads up on the small things that tend to come up in weeks one and two from their end users, the minor bumps that are normal and not cause for alarm. I also remind them of something I say often: we are not doing heart surgery. This is critical to your business and it still is not life or death. If something comes up, we will figure it out together.

How smooth go-live feels is not luck.

Minimal hiccups are the direct result of a process that was documented and communicated, and a UAT period that was thorough, holistic, and honest. If you are heading into that period now, this is what real UAT looks like and how to know when you are actually done. Teams that put the time into quality testing, and genuinely understand their process and their system, have an easier go of it. Teams that skipped UAT, or did the "we clicked around for an hour and it seemed fine" version of it, run into the known unknowns that were always going to surface. They just surface after go-live instead of before, when they are harder and more expensive to fix.

If you are standing at the edge of this leap

Whether you are still on spreadsheets and feeling the weight of them, or you have outgrown a system that no longer fits, here is what I want you to take from this. The overwhelm is real, and it is temporary. This is the hardest leap you will make, and it is also the one that changes the most. A fresh start is not a problem to dread. It is a chance to build something better than what you had, on purpose this time.

What determines how this goes is rarely the software. It is the preparation, the alignment, and having someone beside you who has made this leap enough times to see the end result before you can, and to ask the questions you do not yet know to ask. Get that part right and the rest tends to follow.

Once you are live, the work changes shape again. Activation is its own stage, and the next transition after it has a window that does not stay open forever.

If you are not sure whether you are at Level 1 or somewhere past it, that is worth settling before anything else. The SOMM self-assessment places you in under five minutes and shows you what the next level takes.

Take the SOMM Self-Assessment →

Standing at the edge of this leap?

If you are weighing a move to a new PSA system and want a sounding board before you commit, I am always glad to talk it through. No pitch, just a conversation about what you are walking into. Let's talk.