Did the Customer Move?

There’s a strange thing businesses do once someone becomes a customer.

Before the sale, we talk constantly about change. We talk about getting more leads, saving time, learning a skill, solving a problem, building something new or finally getting rid of something that has been causing trouble for far too long. Whatever brought the customer to us, there was usually something about their current situation they wanted to be different.

Then they buy, and our attention has a funny way of shifting.

The welcome email went out. The appointment happened. Module Three was completed. The website was delivered. The CRM was installed. The application moved to review. The pipe was replaced.

All useful things to know. A business has to know whether it actually did the things it promised to do.

Lately, though, I’ve been thinking there’s another deceptively simple question hiding underneath all of that:

Did the customer move?

──────── ⚡ ────────

Something Happened. But Did Something Change?

I ran into this question while working through customer progression recently.

At first, “customer progression” sounded like one of those ideas that could become unnecessarily complicated in a hurry. Stages lead to milestones, milestones lead to workflows, workflows lead to dashboards, and pretty soon somebody has created a seventeen-stage process for ordering a sandwich.

The useful idea turned out to be much simpler:

What is different about the customer when this part is over?

A business can send a welcome email, for example, but the meaningful change isn't necessarily that an email now exists in someone's inbox. Maybe the customer has moved from “I bought this thing and don't know what happens now” to “I understand what happens next and what I need to do.”

A student can attend six classes without necessarily learning what those classes were intended to teach. A consulting client can sit through a strategy meeting without leaving with a decision they can act upon. Someone can click Complete at the bottom of a course module without being able to apply any of it on Tuesday morning when the real problem shows up.

In each case, we can prove that something happened. That doesn't necessarily tell us whether something changed.

That distinction seems obvious once you see it, which is probably why I find it so interesting that it's also remarkably easy to overlook.

Transformation Doesn't Have to Be Dramatic

Marketing people have been talking about “transformation” forever, and there's good reason for that. People usually aren't buying an object, service or collection of deliverables purely for the pleasure of possessing them. They're buying what they believe having, using or experiencing those things will make possible.

Somewhere along the way, though, transformation became one of those words that can get inflated beyond recognition.

Not every purchase needs to become a heroic journey of personal reinvention.

Sometimes Gary fixes your pipe.

Before Gary arrives, water is appearing somewhere water absolutely should not be appearing. After Gary leaves, it isn't. That's a perfectly legitimate transformation, even if Gary declines to hand you a certificate recognizing your advancement to Level III Residential Wastewater Liberation.

Something useful became different. That's enough.

The same principle becomes a little harder to see with digital services because the thing being delivered can look so much like the result.

Suppose a business hires someone to install a CRM and automated follow-up system. At the end of the project, the provider can quite reasonably say that the CRM has been configured, the pipeline created, the automations activated and the team trained. Those are real deliverables, and getting them right matters.

But why did the customer buy any of that?

Maybe interested prospects had been disappearing into spreadsheets, inboxes and someone's increasingly unreliable memory. If the work succeeds, those opportunities now have somewhere to go, follow-up happens when it's supposed to, the team can see what needs attention, and the owner no longer has to wonder whether somebody remembered to call Susan back.

The software installation is what the provider did.

The change in how the business operates is what the customer got.

That makes me wonder whether we sometimes make transformational benefit harder than it needs to be. Instead of asking how we can make what we sell sound transformational, perhaps the better question is simply what becomes usefully different for the customer because we did our job well.

Sometimes the answer will be enormous. Other times it might be a new capability, a decision someone can finally make, a little more confidence, a measurable improvement or simply the disappearance of a problem that existed yesterday.

The size of the transformation isn't really the point.

The change is.

──────── ⚡ ────────

Activity Is Easier to See

This gets especially interesting when you look at the systems businesses use to manage customers, because most of those systems are naturally very good at recording what the business did.

We know when the email went out, when the appointment happened, when the task was completed, when the invoice was paid, when the document was received and when somebody clicked the button saying they finished Module Three. We need that information; without it, operating the business would be a mess.

What those records can't necessarily tell us is whether anything meaningful became different for the customer.

A support ticket can be closed while the customer remains confused. A course can be completed without the student becoming capable of applying what it taught, just as a perfectly installed CRM can sit there humming away while the business continues losing leads because nobody changed the behavior surrounding it.

The reverse can happen too. One seemingly ordinary conversation might resolve a misunderstanding that has been holding someone back for months. A small implementation could remove an obstacle that has quietly been costing a business hours every week, even though the corresponding entry in the project management system looks like nothing more than another completed task.

That's the gap I've been thinking about.

Once you see it, you start wondering whether some of the things we call customer journeys are actually just business activity logs viewed from the customer's side of the glass.

We mapped what we do next.

We may not have mapped what happens to them.

So How Would We Know?

I don't think the answer is another dashboard containing 37 exciting new metrics.

In fact, one of the simplest ways I've found to think about this is to take a meaningful part of the customer experience and try to complete two sentences:

Before this part of our work, ______ was true.

After this part of our work, ______ should be true.

That's it.

If we're onboarding someone, perhaps afterward they should understand the process and know what happens next. If we're consulting, perhaps they should leave able to make a decision they couldn't confidently make before. An installation might make something happen reliably that wasn't reliable before, while teaching should leave someone able to understand, explain or do something they previously couldn't.

Even Gary has an easy answer.

Before: pipe leaks.

After: pipe does not leak.

Gary remains undefeated.

Once we've identified the difference, then it makes sense to ask how we might recognize it. Sometimes the evidence will be objective: a system works, a document exists, an application is approved or the customer can successfully perform a task. Sometimes the customer can simply tell us what changed. In other situations we may need to observe what happens next before we can reasonably say that progress occurred.

And sometimes we'll discover that we don't actually know how to tell yet.

I like that answer more than I expected to.

It means we found something worth learning rather than filling the blank with a metric merely because the spreadsheet looked lonely.

We don't need to measure everything simply because technology gives us the ability to do so. But it seems worth becoming better at recognizing the difference between evidence that our process ran and evidence that our customer progressed.

──────── ⚡ ────────

Why Did They Enter the Process?

This has started changing the way I think about the work on both sides of a sale.

Before someone buys, we're trying to understand the change they want badly enough to pay for. During the buying decision, we're trying to give them legitimate reasons to believe we can help create it. Once they become a customer, it seems only natural that we should continue following the same thread instead of abandoning it for a checklist.

Is the change actually happening?

That doesn't mean every customer needs to be shoved through an elaborate progression system. Every milestone doesn't need a badge, every interaction doesn't need a KPI, and Gary absolutely does not need seven belts before he's permitted to approach the water heater.

Operational completion still matters. If we promised eight sessions, we'd better know whether eight sessions happened. If the installation requires twelve steps, somebody should probably make sure all twelve were completed.

Completion and progress aren't enemies.

They're just not synonyms.

So here's the experiment I'm taking away from all of this, and you can try it with me.

Pick one thing your business regularly delivers. It could be an onboarding call, consultation, installation, report, lesson, service appointment, project or product.

Forget your internal checklist for a moment and picture the customer immediately before they receive it. Then picture that same customer immediately afterward.

What should now be usefully different?

If you can't answer yet, that's interesting.

If you can, the next question gets even better:

How would you know?

Somewhere between those two answers may be a much clearer understanding of the value you're actually creating—and perhaps a better way to make sure you keep creating it.

Because ultimately, the checklist can tell us whether we moved.

The customer is the one I want to know about.