LinkedIn writing ·
Operational storytelling: telling a client story without breaking confidentiality
Telling a real client story is one of the highest returning content forms on LinkedIn in 2026 and one that most professionals avoid for fear of breaching confidentiality. The result is a feed full of fictional, hypothetical or vague cases ("a client asked me to...") that the experienced reader spots, which switches off the author's credibility.
This article distinguishes what you can tell by default from what you cannot, how to anonymise without diluting the story into something bland, and how to have the conversation with your client that turns a real case into publishable material with no friction afterwards.
By Sheena de PunkVoice · Edited by Mario Pérez
Why the real case pays off and the fictional one gets spotted
A real case has awkward concrete details a fictional one never imagines: the client's mistake that delayed the decision, the meeting where somebody walked out, the exact metric that came in below target. Those details are what make the story credible and memorable, and they are what an invented or vague case cannot provide, because nobody would put them in an educational example.
The professional reader has had three or four years of training in telling the difference. A post that opens with "imagine that..." or "a client asked me not to give details but..." sets off an immediate alarm and lowers the author's perceived quality for months. In 2026, with the stylistic classifier penalising the generic, hypothetical cases also perform worse in reach because they share vocabulary patterns with the rest of the simulated feed.
What you can tell by default and what you cannot
Unless your contract has a specific clause, there is a wide band of material you can publish without asking permission because it does not breach confidentiality. And there is a sharp line that always does. Telling them apart honestly saves 90% of the awkward conversations.
- Allowed by default: the type of challenge you tackled (not the brand), your internal working process, generalisable lessons, the judgement you used to make decisions during the project, your own mistakes that you corrected.
- Allowed if you anonymise well: approximate industry (not exact), company size as a range (not headcount), the project stage, the result in orders of magnitude (not precise figures).
- Not allowed without explicit permission: the company's name, people's names, specific revenue or investment figures, internal business decisions, non-public strategic information, any document or material.
- Never allowed, even with permission: information that harms third parties (staff who were let go, suppliers whose relationship broke down), data under an NDA that survives the project, information that gives an advantage to the client's competitors.
Anonymising without diluting the story into something bland
The most frequent mistake when anonymising is removing so many details that the story stops saying anything. "I worked with a company" loses all density; "I worked with a mid sized industrial company in northern Spain in a European expansion phase" keeps what matters without identifying anyone.
The operating rule is to replace every identifying detail with its useful category. Company X becomes "a technology consultancy of 40 to 80 people"; CFO Y becomes "the CFO, who had been in the role for two years"; 32% growth becomes "sustained annual growth above 25%". The useful category keeps the story intelligible and protects the identity.
The details that bring a story to life are rarely the ones that identify people. That the team met on Tuesdays at nine, that there was a post-it on the office wall summarising the value proposition badly, that the CEO took her coffee at the machine rather than in her office: none of this identifies anyone, and all of it turns an abstract anecdote into a recognisable scene. That granularity of harmless secondary detail is what separates the memorable publishable case from the bland one.
The conversation with the client before publishing
Best practice in 2026, if you are going to tell an identifiable case or one with specific figures, is a brief conversation with the client before publishing. Not a permissions form; a five minute adult conversation. The sequence that works is this.
- Show them the draft before you write the post. One paragraph with the story you want to tell and the lesson you want to underline. No design, no polished copy, just the substance.
- Ask what bothers them. There are usually one or two details they identify as sensitive that you would not have spotted. Swap them for their useful category.
- Offer two versions: with their name visible and anonymous. A third of clients accept being named because the visibility benefits them; two thirds prefer the anonymous version. Having both options on the table avoids the false choice between naming them or saying nothing.
- Confirm before publishing. Email them the final post. Five minutes of waiting avoids months of friction if something slipped past them in the initial conversation.
The four classic mistakes when telling cases on LinkedIn
The failure patterns are stable and appear combined in most posts that worsen the author's profile instead of improving it.
- Telling the case as a personal triumph with no agency for the client. "We doubled their revenue" erases the client's work and sounds like bragging. The version that pays off recognises everyone's role, including yours.
- Telling the case with an obvious moral ("the lesson is to listen to your client"). The reader draws their own conclusions if you give them the scene; they close down if you hand them the moral ready made.
- Telling the case with exact figures when an order of magnitude was enough. Exact figures identify people and add nothing; the order of magnitude communicates the impact without compromising anyone.
- Telling the case with no difficulty in it. Real projects have friction, doubts and bad moments. Leaving them out makes the story suspicious; including them with judgement makes it credible and useful.
What to do when the client says no
It is not a failure, it is information. If the client prefers you not to tell their story even anonymised, respecting that decision is what sustains the relationship and your professional reputation long term. There are two productive paths.
The first is shelving the case until conditions change (the end of the project, a change in the public picture, enough distance in time). Many cases can be told two or three years later with the perspective of time, with no friction.
The second is writing the lesson without the case. A generalisable lesson does not require a case; it requires judgement of your own and hypothetical examples clearly labelled as such. "In recent years I have seen several projects where..." is honest and publishable, and it compromises nobody.
Long articles on LinkedIn: when they make sense and when they do not
The real case as an asset, not a risk
Telling real, well anonymised cases is one of the most profitable editorial practices on LinkedIn in 2026, and it is not incompatible with confidentiality when done with judgement. The rule is simple: replace identifying data with useful categories, keep the harmless secondary details that give it life, and talk to the client when the case is recognisable.
The result is a personal feed with the density of real experience, instead of a feed full of hypothetical examples that all sound the same. That density is what a CV or a landing page cannot achieve, and what in 2026 still separates a professional with judgement from one with well formatted generic content.