How to Do Employee Advocacy With AI Without Writing Everyone's Posts

The fastest way to bring AI into an employee advocacy programme is also the one most likely to kill it. Marketing writes one announcement, asks a model for twenty variations, and sends one to each person. Every post is technically different. Anyone who follows three of your colleagues still sees the same news, the same shape, and the same adjectives three times. None of the posts carries the knowledge that made those people worth following in the first place.

AI is more useful in other parts of the process. It can pull expertise out of busy people, turn their own words into a first draft, and check that draft against what they actually said. The employee stays the author the whole way through. This is the workflow, starting with the limits LinkedIn places on any tool you use.

Start with LinkedIn's rules, because they decide the tooling

LinkedIn's User Agreement (effective 3 November 2025) has three provisions that matter for AI-assisted advocacy:

This is our reading of the agreement, not legal advice. Check the current text and your own policies before you choose a tool.

Publishing is a different question from engagement. LinkedIn grants posting permission to approved apps through its official connection flow. A tool that publishes a post the member has already approved, at a time they chose, is doing something different from a bot generating likes. When you evaluate a vendor, ask which of the two it does.

Give the model a source pack for each person

A campaign brief tells a model what the company wants to say. Employee posts need different input: what this particular person knows. For each contributor, put together four things:

• Their own account of the topic. An interview transcript or voice note. This is the only permitted source for opinions, stories, lessons, and feelings.
• An approved facts sheet. Product names, dates, what is public, and any numbers that have been cleared for sharing. Company messaging goes in here as facts, not as phrasing to copy.
• Writing samples they choose. A few of their own posts or emails, shared with permission, so the draft can follow their sentence length and vocabulary.
• Their "never" list. Phrases, claims, and subjects they will not put their name to.

Keeping these separate is what makes the later checking possible. If a draft contains a lesson, you can trace it to the transcript. If it contains a date, you can trace it to the facts sheet. Anything that traces to neither was invented.

Let AI run the interview

The bottleneck in most programmes is not writing. The engineer who understands the problem has twenty minutes between meetings and no desire to stare at a blank post. An AI interviewer fits that gap because it can ask follow-up questions at whatever time suits them.

A prompt that works:

You are interviewing [name], a [role], about [topic] for a LinkedIn post they may decide to write. Ask one question at a time. Begin with a specific recent situation, not their opinion of the topic. When an answer is general, such as "it really helps teams", ask for the instance they are thinking of. Do not suggest answers or praise them. Stop after eight questions, or earlier if they say stop.

A five-minute voice memo recorded on a walk works too. A transcript of someone talking usually contains better material than anything they would type, because people explain things more plainly out loud.

A worked example: one release, three authors

Take a fictional inventory software company releasing offline scanning, so warehouse staff can keep counting stock where the Wi-Fi drops.

The variation approach produces three versions of the same post: "Excited to share that offline mode is here", "Big news for warehouse teams", and "Thrilled to announce". Each one restates the release note in different words.

Interviews produce three different posts, because the three people experienced the release differently:

• The support lead noticed the problem first: tickets from warehouses whose back rows had no signal, and staff who were writing counts on paper and typing them in later. Their post is about recognising a workaround hidden inside support tickets.
• The engineer spent most of the project on one decision: what happens when two people adjust the same item's count while both are offline. The team chose to keep both changes and ask a manager, instead of letting the later one overwrite the earlier. Their post explains that choice.
• The account manager now asks one new question during onboarding: "Walk me to the place where your Wi-Fi drops." Their post is that question and why it matters.

Only one of the three needs to mention the release, and it can link to the company page announcement for the details. The release gave all three a reason to post; what they wrote came from the interviews.

Here is a draft the engineer's notes might support:

Two people count the same pallet while both are offline. One says 40, the other says 38. When they reconnect, which number wins?

Our first instinct was "the latest one". We dropped it, because the latest count only tells you whose phone found signal first.

We now keep both and ask the warehouse manager to choose. It's slower. It's also the only version where nobody's count silently disappears.

If you've built offline sync, I'd like to know how you handled this.

Nothing in it needs a number the engineer cannot support, and the closing question is one they would genuinely like answered.

Draft from their words, then check against them

A drafting prompt for team use:

Draft a LinkedIn post for [name] using only the interview transcript and facts sheet below. Keep their position and their level of certainty, and use their own wording where it is clear. Do not add numbers, customers, emotions, anecdotes or opinions that are not in the transcript. Avoid these phrases: [never list]. After the draft, list each sentence that relies on the facts sheet, and any gap where you needed information you did not have.

Then run two checks before anyone sees the draft.

Check the draft against its sources. In a fresh conversation, give the model the transcript, the facts sheet and the draft, and ask: "List every claim in the draft that neither source supports." This takes less time than a careful human read and catches the most damaging error: a fluent sentence that was never true.

Check the week's drafts against each other. Put every draft scheduled for the week into one prompt and ask which openings, phrases and structures repeat across them. Models drift towards one house style even when each draft comes from a different person. A tidy repetition you would never notice in a single post becomes obvious when four colleagues use it on the same day.

Keep approval and publishing with the employee

The author approves the exact text that will be published. If anyone edits it afterwards, the edit goes back to them. They publish from their own account, either directly or through a tool connected with their own sign-in. They can decline any post, and a voluntary programme makes clear that declining has no consequences.

Engagement stays human as well. AI can usefully point out which colleague's post is relevant to whom: the engineer's post on sync conflicts will interest the support lead. The reaction and the comment, though, belong to the person. Do not generate comments for colleagues to paste under each other's posts. Even if a human clicks send, a thread of similar praise looks coordinated to anyone who reads it.

Decide on disclosure together

Two separate questions tend to get mixed up here. The first is the employment relationship: when someone talks about their employer's products, readers should be able to tell they work there.

The second is AI assistance. The User Agreement provisions above require review and responsibility. Check LinkedIn's current policies, and any rules in your sector, for anything further. Beyond those, agree a position as a team. Some authors are happy to mention that they drafted with help; others treat AI like a spell checker. What matters is that nobody presents an AI-written opinion as their own considered view when they have not considered it.

Use AI on the responses, too

Once a post is live, the useful signal is usually in the replies, not the reaction count. With the author's agreement, paste the comments and any direct questions into a model and ask it to sort them into questions, objections and requests. The questions become next month's interview topics, which gives the programme a source of material that does not depend on marketing inventing angles.

This matters more since LinkedIn removed its employee advocacy reporting in 2024 and 2025. Track what remains and connect responses to outcomes without counting every impression as a lead.

Measure what the workflow costs

Track the interview time, review time and number of revision rounds for the first few posts each person publishes. If the AI saves drafting time but every post needs three rounds of fixing invented details, the process needs tighter sources, not a better prompt. If people stop agreeing to interviews, find out why before adding more contributors.

FeedSquad, which publishes this blog, is built around the same constraints: drafts come from a person's own material and voice, nothing is published without their approval, and posting goes through LinkedIn's official connection.

Sources

• LinkedIn: User Agreement, sections 2.2, 3.6 and 8.2 (effective 3 November 2025)