How to Turn Client Experience Into LinkedIn Posts Without Breaking Confidentiality

A client story has a sequence: who had the problem, what happened, what the advisor discovered, and what changed.

A useful lesson needs much less. It may require only the mistaken assumption, the variable that changed the decision, or the question other people should ask before taking the same path.

Consider this hypothetical draft:

Last month, a 75-person Toronto software company asked me to create an AI policy two weeks before a major insurer's security review.

The company is not named, but the combination of location, size, industry, timing, and event may be enough for the client, its employees, insurer, competitors, or mutual contacts to recognize it.

The lesson can survive without those details:

Smaller companies often begin AI governance when a customer, insurer, or procurement team asks for evidence. By then, the immediate need is not a perfect policy. It is a defensible inventory of how AI is already being used.

The second version shows professional judgment without turning one engagement into a public case narrative.

Names are only one way to identify a client.

Industry, city, job title, company size, project date, precise results, unusual circumstances, and recognizable language can become identifying when they appear together. A detail that looks harmless by itself may complete the picture for someone who already knows part of the story.

Canada's privacy regulator uses a similar test when considering whether information has been made anonymous: there should be no serious possibility that a person can be reidentified from the information alone or in combination with other available information.

That does not mean every general lesson from client work is prohibited. It means "I did not use the name" is not a sufficient review standard.

The practical question is wider: who could recognize the client after combining this post with what they already know?

Before turning client experience into a post, review it through five steps.

Write the insight in one sentence before writing the story.

What changed in your thinking? Which assumption was wrong? What should someone in a similar situation check or do differently?

If the lesson works without the engagement narrative, leave the narrative out. The objective is to demonstrate how you think, not prove that a particular client hired you.

Remove or broaden details that do not change the lesson.

That can include names, locations, dates, titles, headcount, revenue, project duration, technology choices, exact outcomes, direct quotations, screenshots, filenames, and unusual sequences of events.

Changing one detail while preserving the rest is not always enough. A client may still be obvious from the combination.

A recurring pattern is often safer and more useful than a single case.

Instead of writing, "A client made this mistake last week," explain that the same assumption appears across several engagements and describe the general consequence. Aggregation moves the post away from one identifiable event and toward professional observation.

Only call something a pattern when it is one. Do not combine unrelated details into a fictional success story, invent an outcome, or make one experience sound like broad evidence.

Check the engagement agreement, nondisclosure terms, professional code, employer policy, and relevant privacy requirements before using client-related information.

In regulated professions, duties can be stricter than an ordinary expectation of discretion. FP Canada's professional standards, for example, require client information to remain confidential and require written, informed consent before personal or confidential information is disclosed or used, subject to defined legal and regulatory exceptions. The duty continues after the engagement ends.

Consent should not be treated as a casual message saying, "This is fine." Where consent is appropriate, the client should understand what will be published, where it will appear, which details remain, and how the material will be used. Depending on the profession and circumstances, publication may still be inappropriate even when the client agrees.

Read the draft as four different people:

Could any of them identify the organization or person? Could the post reveal an internal problem, decision, relationship, result, or timeline that was not already public?

If the answer might be yes, remove more context or publish the general principle without the case.

• The client
• Someone who works with the client
• A competitor familiar with the situation
• A mutual contact who knows you worked together

The most obvious confidential facts are usually removed first. The less obvious details create the remaining risk.

Review drafts for:

Precision can make a post feel credible. It can also make the subject easier to identify. Keep a detail only when it materially improves the reader's understanding and you are permitted to disclose it.

• Industry combined with a city or region
• Exact headcount, revenue, budget, or project value
• A precise date, deadline, or engagement duration
• A rare role, technology, incident, or business condition
• Verbatim language from a meeting, email, or document
• Exact improvements, losses, percentages, or financial results
• Screenshots containing interfaces, metadata, usernames, or filenames
• A sequence of events recognizable to insiders
• Several broad details that identify the client when combined

Client-derived insight does not require a miniature case study. These four formats keep the emphasis on the advisor's thinking.

Describe something seen across multiple genuine engagements, then explain why it happens and what readers should watch for.

"Teams rarely lack an AI policy because nobody cares about governance. More often, nobody owns the inventory needed to make the policy accurate."

The value is in the pattern and implication, not the identity of the organizations behind it.

Share a test used to choose between options.

"Before adding another security tool, identify whether the control failure comes from missing capability, weak configuration, or unclear ownership. A new product solves only one of those problems."

This demonstrates practical judgment without discussing a client's implementation.

Explain how experience changed a professional assumption.

"I used to treat executive sponsorship as the starting condition for governance work. In smaller organizations, a credible operating owner is often more important at the beginning. Sponsorship matters, but ownership determines whether the first controls survive contact with daily work."

The post is about the evolution of your thinking, not the engagement that prompted it.

A composite scenario can combine recurring, non-identifying characteristics to explain a common problem. Label it as a composite so readers do not mistake it for one factual client story.

Do not fabricate results, quotations, or evidence. If the lesson does not need a scenario, the simpler option is to omit it.

Permission can be necessary without being sufficient.

A client may agree because they want to be helpful, because the request comes from a trusted advisor, or because they do not yet understand how widely the post could travel. A professional still has to consider contracts, regulatory duties, privacy, accuracy, and the effect on the relationship.

When a named client story would genuinely help both parties, develop it with the client rather than presenting a finished post for quick approval. Agree on the purpose, facts, wording, channels, timing, and review process. Put the approval in the form required by your profession and agreement.

Do not assume that information is available for marketing because it appeared in a meeting, because the engagement ended, or because the client disclosed part of it elsewhere. Public platforms collapse audiences. A fact shared in one context does not automatically belong in another.

AI can help remove names, broaden details, restructure a case as a general lesson, and flag language that appears identifying.

It cannot know every fact held by the client's colleagues, competitors, or community. It may not know the terms of your engagement, the expectations created in a private conversation, or the rules of your profession. It cannot decide whether publication would damage a relationship even if the wording is technically permissible.

The expert still owns the disclosure decision.

When using AI to draft from client experience, provide the minimum information necessary. Do not paste confidential records, meeting notes, personal information, or proprietary documents into a system unless you are authorized to do so and the system is approved for that data.

The purpose of the tool is to help express the lesson. It does not need the client's complete story to do that.

Before approving a post, ask:

• Does the lesson still work without the client narrative?
• Is every remaining client-related detail necessary?
• Could the client recognize themselves?
• Could a colleague, competitor, or mutual contact identify them?
• Does the agreement or professional code restrict this use?
• If consent is required, is it specific, informed, written, and current?
• Have any quoted language, screenshots, metadata, or exact results survived the edit?
• Would publishing this strengthen or weaken the client's trust?

A doubtful answer is a reason to stop, not a prompt to make the disclosure sound more anonymous. Rewrite the post around the pattern, share the decision rule, explain the professional lesson, or choose another source entirely.

The strongest client-informed post is often not a story about what happened. It is the principle that became clearer because it happened: the question you now ask earlier, the boundary you learned to add, or the signal that changes your recommendation.

Share that part.

A post is not worth publishing if credibility with strangers comes at the expense of trust with the people you already serve.