You’re not lacking equipment, you’re lacking an owner.
That’s what the team of the person who had bought our product told them when they asked how they were using it.
Yes, a month. And yes, it happens.
Everyone has experienced this at some point with products that aren’t one hundred percent mature, but what stuck with me wasn’t the month—it was that account being discussed every week in the committee.
It was Tier 1, one of those accounts that carry weight in your company and appear on the agenda week after week. On top of that, there was an open conversation with marketing and sales about a possible collaboration with them, so the general feeling in those meetings was good and there was this sense of a “controlled account”
In the meetings, people would say: “They opened a ticket, but product has it”, and that was true. What no one said was that product needed the support team to close it, and that support hadn’t seen it because of the volume it was dealing with. Each team had done its part and passed it on to the next.
CS knew nothing, no one had raised their hand, so no one paid attention to it.
It ended well, considerably better than well, and I’ll tell you about it at the end.
Today, when I tell this story and ask who owns the account, the answer I almost always get is some variation of the same thing:
“Well, that’s really everyone’s responsibility.”
And that’s where the problem begins, because when something belongs to everyone, work almost always starts too late because of a lack of ownership and system.
The org chart you draw and the one you need
That org chart had all the names on it, but if you look closely, one function was missing.
Most org charts are drawn based on the people you already have, not on the functions and processes the business needs to happen.
A few weeks ago, I read a book that puts a name to this: Verne Harnish’s book Scaling Up. which recommends starting the other way around, starting with the functions that need to be covered, making it clear who is accountable for each one, and only then adding names.
And this is the same criterion I used to and still use when working, because if you take it up to the level of profiles, skills, or competencies, the org chart is designed as a flow, and your org chart should describe a business model, not a portrait of your workforce.
In sales, this is usually done and looks clean: someone prospects, someone closes, someone reports, someone is accountable for the number. But when we bring the exercise to post-sales, empty boxes start to appear.
But in your company and on your team, you should NOT hire to fill gaps. You should hire to cover functions, design the system, and scale. .Everything is discussed. Not everything has an owner.
Sales is bringing in new business, and it can care about the existing portfolio, of course, but it can hardly prospect, close, and look after every account at the same time, because its number, and its actual efforts, are focused elsewhere.
And then there’s the other version, which I’ve also seen: the deal is signed, it’s celebrated, and goodbye, fish. Follow-up is no longer my problem.
In your company, one is a matter of not being able to and the other of not wanting to. But the customer doesn’t see your org chart; they only see that no one calls them.
Whoever is in contact with the customer after the contract is signed, (in the example, Support and Product) usually has the most frequent relationship with the customer. They see them the most, talk to them the most, and notice first when something starts to go wrong. But their work is designed to deliver, resolve, and fulfill commitments; besides, no one has explicitly asked them to monitor whether the account is progressing, whether it’s getting value, whether signs of risk are emerging, or whether the conditions exist to keep growing together.
And then the weekly meeting arrives, the one where new opportunities, blocked customers, incidents, accounts that could expand, upcoming renewals, and customers beginning to raise concerns all get mixed together.
Everything is discussed, but almost nothing comes out with an owner and a date.That’s why many companies find out that an account is having doubts only after it has already been having them, when it stops responding, questions the price, a competitor appears, or the renewal is already on the table and the only thing left to decide is how much of a discount to offer.
This isn’t a people problem
And here comes the part that’s hardest to accept, especially when the team is good.
Because in the story I told you at the beginning, no one did their job badly. Support logged the ticket and escalated it, Product requested what it needed to close it, and Sales was building a new opportunity with that same account. Each piece did exactly what was expected of it.
And yet, the customer was stuck for a month, without focus or attention being given to the issue.
That’s what took me a long time to understand: you can have a team that does everything right and a customer who experiences everything badly, because what fails isn’t inside any of the boxes on the org chart; it’s between them.
What was missing was a function the business needed that didn’t appear on anyone’s org chart: someone accountable for the account’s progress after the contract is signed.
Not for customer satisfaction, and not for support. For the progress of both customer and company.
And those are different things, even though they’re constantly confused.
A customer can be happy and not be growing. A customer can have no formal complaints open and still have been unable to work for a month.What “owner” means
And here we need to clarify something, because when I say owner, many people understand “the person who does everything,” and that’s not it.
Being the owner means three fairly specific things.
The first is that someone is accountable. When you ask how that account is doing, there’s a person who answers, and answers with data, not a feeling. Be careful with this, because “I think they’re fine” isn’t an answer; it’s hope.
The second is that there’s a moment in the calendar. That account is reviewed before the renewal is near, in its own space and according to a specific criterion, not inside the meeting where everything is discussed at once. For example:
- Portfolio review, monthly. All accounts, using a traffic-light system. It’s for detecting issues, not resolving them.
- At-risk account review, weekly or biweekly. Only those that are red or amber. It ends with an action, an owner, and a date.
- Renewal preparation, triggered by the calendar. Ninety or one hundred and twenty days before expiration, not when the notice arrives.
- Growth review, quarterly. Healthy accounts. This is the one that never exists, and it’s precisely where the growth no one saw coming is usually found.
The third is that this person has authority. If they detect a risk and fixing it requires Product to prioritize a bug, Support to escalate a ticket, or Sales to put an expansion on hold until the customer is stable, the question is simple: can they make it happen, or can they only ask nicely and wait?
And this third one is the most frequently skipped, because it’s the uncomfortable one. You can set up the first two in a week, but the third forces you to address how decisions are made in your company.
If you appoint someone responsible for renewals but don’t give them the real ability to move Product, Support, or Sales, six months later you’ll have a frustrated person updating a dashboard no one looks at.
And that isn’t appointing an owner. That’s appointing a witness.How that account ended up
I told you at the beginning that this ended well, so let me tell you about it.
When I found out that Sales was exploring that collaboration, I asked Support what the customer’s actual situation looked like, because it made no sense to make a move without knowing where we stood.
And that’s when the incidence appeared: it was critical and had been open for a month.
Almost at the same time, the customer raised it with Sales.
What we did was step forward: we took over communication from CS, with constant updates, and told them that, since it was a serious failure, we wanted to support them in a specific way: transparency, follow-up, and a proposal to adjust their workflow.
Their response was that they had never been treated that way before, and that they could see the changes in the organization.
And once that channel opened, what usually happens when someone is finally talking to the customer for real happened: we proposed improvements to the way they worked, showed them modules that suited them, and they adopted all of them.
A poorly managed incident ended in a six-figure upgrade.But the uncomfortable part is something else, because that wasn’t produced by a system. It was produced by a question I asked for a reason that had nothing to do with that incident: Sales was moving something forward, and I wanted to know where we stood.
If I hadn’t asked that week, the incident would still be open, the customer would have been unable to work for another month, and the renewal would have arrived with all that silence behind it. So it’s not just that we didn’t have an owner in the process; we were also lucky and luck shouldn’t be part of the company’s org chart.
Before hiring anyone
If you manage accounts or deliver the service: look at your five largest customers. Could you say today which one is at risk and why, without opening the CRM and without using the word “think”?
If you lead the team: look at your last weekly meeting. Of the accounts discussed, how many ended with someone having a specific action and a date?
If you’re a COO or CEO: take your org chart and cross out all the names. Leave only the functions. Which ones are left without anyone behind them?
Because before discussing whether you need more people, more teams, or more tools, the question is a different one.
Which functions does your post-sales model truly need, and who is accountable for each of them today?
If an empty box appears when you make that list, you already know where to start, although the problem is that almost never is there just one.
What I’ve told you here happened to me as soon as I joined that company, and it was precisely what led me to design the process so it wouldn’t happen again. Not to put out that fire, but to make sure the next one didn’t arrive by chance.
If answering the three questions above has left you feeling uncomfortable, write to me and we’ll take a look at it.
👉🏻I’d love to hear from you: if you’ve already faced this, what has been the hardest thing for you, or what do you still struggle with?
Artículos relacionados
