Why an executive sometimes finds out about problems from their clients

An executive who finds out about a problem from their client does not have a client problem: they have a problem with how information circulates. The information existed in their organization, with someone, somewhere. It did not make the trip to them, or not in time, or not in a form they could use. The client only had to pick up the phone.

We see this regularly in the field, in well-run companies, with capable teams and good tools. This article tells three situations we have encountered, without any name or detail that would identify anyone, then draws out the causes, a method and tools you can use this week.

What happens when leadership hears about a problem from its client?

Three things almost always happen, whatever the situation:

• The relationship changes nature. You wanted to talk about the future (a renewal, an extension, a payment) and you end up talking about trust.
• Leadership reacts without knowing the facts. It apologizes, promises, applies pressure, before knowing what really happened.
• The teams receive pressure that was not meant for them, or that lands on the wrong people. Those who are not at fault receive it, and those who know have not been asked.

In the long run the loss is wider: the executive’s credibility, the teams’ trust (people stop reporting what is badly received) and their negotiating position. The three situations below each illustrate one of these effects.

Situation 1: the renewal that turns into an explanation

The head of a service provider visits an important client for a commercial meeting: the contract is about to expire and its renewal is to be renegotiated. The same day, one of the provider’s technicians carries out an operation on the client’s site and causes an incident that stops part of the production.

The meeting does take place. But instead of negotiating, the two executives talk about the loss of trust. Each calls their own teams to understand what is going on: the provider’s executive learns what their technician did at the same moment as their client, in the same room.

What really happened. Nobody made an obvious error of judgment: the technician had a planned task, the executive had a commercial meeting. But neither knew what the other was doing at this client that same day. The two events existed in two calendars, and no view showed everything going on at this client.

What would have changed. With a single view of every event planned at a client (meetings, interventions, committees), the executive would have seen the day before that a sensitive operation was scheduled on the day of their negotiation. They could have postponed it, secured it, or at least prepared for it. It is not a guarantee against the incident: it is the possibility of not stacking a decisive commercial moment on top of a risky operation.

Situation 2: the delay whose cause lies on the other side

A client calls the head of a service provider. They are unhappy: a delivery expected for a long time has not happened. The executive apologizes and then, in front of the client, puts pressure on their teams to deliver what was expected.

But they address people who do not know the reality of the situation. The reality is that the teams have been waiting for weeks for structuring documents that the client was supposed to provide. They chased them several times, without an answer. They cannot move forward.

What really happened. The information "we are blocked, waiting for the client" existed. It circulated in email exchanges among a few members of the project team. It had not reached leadership, and it was not visible on the client side either, where nobody connected their own pending request with the delay they were complaining about.

What would have changed. With direct access to the state of the project, without having to ask their teams, the executive would have seen, even before the call, that the pending actions were on the client’s side. On the phone they could have answered calmly: we have been waiting for the documents since this date, here is what was requested, here is what is blocking. No more unjustified pressure on the teams, and a direct request to the client, who is faced with their share of responsibility.

Situation 3: the invoice nobody pays because "it was not delivered"

A client is slow to pay. When the provider’s executive follows up, the answer comes back: the client says the delivery was not made, and therefore owes nothing.

In reality, the delivery did take place. The client’s own teams even received it and signed the acceptance. But the client’s executive was not informed: the information stayed at the level of their teams. They defend, in good faith, a position that is wrong, and their supplier has to prove to them what happened inside their own company.

What really happened. An information asymmetry between two executives, each of whom has, in their own organization, teams who know. The provider knows it delivered, the client’s team knows it accepted the delivery, but neither executive reads the same thing. The discussion is about a version of the facts that is nobody’s.

What would have changed. If the acceptance is recorded in a place both executives can read, with its date and the client’s validation, the discussion does not take place. Each sees that the delivery was made, that it was validated, and that the invoice is due. The late payment goes back to being what it is: a payment matter.

Why it happens: the organizational causes

These three situations do not share the same details, but they share the same causes. None of them is an individual fault.

Information is scattered

The schedule is in a file, the exchanges with the client in emails, the interventions in each person’s calendar, the acceptances in documents or messages. Each tool holds a part of the truth, nobody has the sum. Answering a simple question about a client means asking several people.

Nobody is in charge of warning leadership

In many organizations the answer is implicit: "whoever sees it". In other words, nobody in particular. People wait until the deviation is certain before reporting it, and it generally is when the client notices.

Rituals leave little room for deviations

A committee whose slides are reused from the previous month talks about progress. Deviations are not discussed because the format does not expect them, and what is not recorded does not exist for those who were not in the room.

Announcing a delay is costly for whoever announces it

When a deviation is received as a fault, it is announced as late as possible: this is the normal response of an organization that handles bad news poorly. The team in situation 2 had chased the client, but had not dared tell their leadership that the client was blocking them: it would have sounded like an excuse.

Decisions come late

Even when informed, leadership sometimes decides too late: no threshold says when it must step in, no role says who decides in its absence. The deviation waits for a decision that nobody feels authorized to make.

How do you organize the path of information?

You do not fix this problem by asking for more reporting, or by multiplying reminders. You fix it by organizing the path of information. Five principles.

1. One reference point per client. What has been ordered, delivered, accepted, invoiced and what is expected from the client, in a single place, readable by leadership without going through anyone.
2. A view of everything going on at a client. Meetings, interventions, committees, deadlines: the same calendar for everyone who works there. This is what prevents situation 1.
3. What is expected from the other side is recorded as such. A request made to the client is an action, with a date and an owner on the client’s side. This is what prevents situation 2.
4. The client’s validations are dated and visible on both sides. A signed acceptance can be found, not only in the file of whoever received it. This is what prevents situation 3.
5. A deviation is reported when it is seen, not when it is certain. This rule only holds if leadership receives the deviation as information, not as a reproach.

Who warns whom, when, and who decides

A table to fill in for one client or one commitment, in a one-hour meeting. It makes explicit what is implicit today.

A twenty-minute weekly check-in

A short, regular ritual devoted to deviations, whose decisions are recorded. Four questions are enough, asked for each client followed:

1. What is planned at this client this week and next?
2. What do we expect from them, and since when?
3. What do they expect from us, and are we on time?
4. What decision has to be made, and who makes it?

At the end, three lines recorded: what was decided, by whom, by when. They can be read, if needed, by someone who was not there.

Ten questions to know where you stand

Answer yes or no, without looking up the answer: if you have to look, that is already an answer.

1. If a client called you this morning, could you answer without calling anyone?
2. Do you know what is planned this week at your three main clients?
3. Can you say what your teams expect from your clients, and since when?
4. Are your clients’ acceptances and validations recorded in a place you consult?
5. Who is in charge of warning you about a deviation before the client does? Can you name them?
6. Do your committees talk about deviations, or only about progress?
7. Has a deviation you know about been waiting for a decision for more than two weeks?
8. Do your teams dare to announce a delay to you, or do they wait until they can justify it?
9. If an incident occurs at a client, do you know within the hour who was working there and why?
10. Does your client read, as far as possible, the same thing you do about what concerns them?

More than four "no" answers: the problem is not with your clients, it is in the path of information.

Where to start: thirty days, one client

There is no need to change everything. Choose a client, an important one but not a critical one.

• Week 1: map. Gather on one page everything that happens at this client (projects, contracts, interventions, deadlines) and what is expected on each side. Fill in the "who warns whom" table for this client.
• Week 2: assign. One owner per commitment, with the rule "a deviation is reported when it is seen". Leadership announces how it will react: it says thank you, it does not reproach.
• Week 3: hold the ritual. The twenty-minute check-in, every week, at the same time. Record the three lines.
• Week 4: measure. How many deviations were reported before the client saw them? How many decisions were made during the week? What is still implicit? Then extend to a second client.

Common mistakes

Multiplying reports (more documents, not more clarity), asking for everything to be escalated without saying what leadership will do with it, buying a tool before deciding who enters data and who reads it, trying to cover everything at once, or treating the symptom at the client (apologizing, promising) without treating the cause: the same call will come back.

And the tool, in all this?

Software creates neither responsibility nor ritual, and it does not replace the rules above. It can, however, make what the method requires sustainable, and spare you from rebuilding the information by hand. This is the principle behind pylotik, the operational commitment management software we publish. Let us go back to our three situations.

• Situation 1. Each client has its calendar, which brings together the meetings and interventions that concern it: the executive sees what is planned there before going.
• Situation 2. Pending actions, including those on the client’s side, are recorded with their date. The executive consults the state of the project without asking their teams, and can answer the client with facts. The client sees, on their side, what is requested from them.
• Situation 3. An acceptance validated by the client is dated and viewable by both sides: the client’s executive, with their free access, sees the validation made by their own teams.

Three limits, which we prefer to state. The tool does not warn anyone for you: it shows what has been entered, and the information displayed is what the teams have recorded. It does not replace the discipline of keeping it up to date: an action that is never recorded will not appear. It does not handle incidents as they come: it is not a support tool. It can be used without any consulting engagement, and we work without imposing it: the product page details what it does and what it does not do.

The tool does not settle the underlying question, and neither does a polished report. We explain why in another article on reporting and a shared operational view. If your situation resembles one of the three above, we also work on drifting projects.

Frequently asked questions

Why is the client sometimes the first to know about a problem?

Because the information exists inside the organization but does not reach leadership: it is scattered across several tools, nobody is assigned to report it, and rituals leave no room for deviations. The client, for their part, sees the result directly.

What should you do when a client complains about a delay they caused themselves?

First check the facts before reacting: what was asked of the client, when, and what did they reply? Then do not put pressure on the teams that is not theirs to bear. Finally, show the client, without aggression, what is pending on their side and since when. This is much easier when these expectations are recorded with their date, rather than in emails nobody has at hand.

How do you avoid stacking an important commercial meeting and a sensitive intervention at the same client?

By having, for each client, a single view of everything planned there: meetings, interventions, committees. Before an important meeting, someone consults it and, if necessary, decides to move or secure an operation. This requires interventions to be planned in a shared tool, and not in everyone’s own calendar.

How do you prove to a client that they were delivered when they dispute it?

By recording the acceptance in a place both parties can read, with its date and the validation of the team that signed it. The discussion is then about payment, not about whether the delivery happened. If the information stays in documents internal to each side, a good-faith dispute is possible.