23 LinkedIn Post Templates That Leave Room for Real Evidence

A LinkedIn template can help organise an idea. It cannot supply a real result, customer experience or opinion you do not hold. Use the structures below after gathering the material, and keep unresolved placeholders out of the published post.

None of these templates has been tested for reach. Each example is built on a scenario stated in the sentence before it. Replace the scenario with your own facts before you publish anything.

Pick a template by what you have

Start from the material you have. If you have nothing in the left column, you are not ready to write the post yet.

Once you have the template, choose how to carry it with the post formats guide. A procedure may be better as a document than as text.

The five core templates

1. Explain a distinction

Structure: People confuse [A] with [B]. The difference matters when [situation]. Check [observable detail] before [decision].

Example:

A scheduled post and a published post are different states. The distinction matters when delivery fails after approval. Check the publication result before marking the campaign item complete.

Use this when a small conceptual difference changes an action. Define unfamiliar terms rather than assuming the reader knows your internal workflow.

2. Explain a decision

Structure: We chose [option] because [constraint]. We gave up [tradeoff]. We would reconsider if [condition].

Say your team maintains the setup guide for a B2B tool:

We kept the setup guide on one page so a new user can see the whole sequence. That makes the page longer, and some steps won't apply to everyone. We'll split it if testing shows people cannot find their starting point.

Replace the example with a decision your team really made. Do not add an invented debate or a dramatic deadline.

3. Teach one procedure

Structure: To complete [task], start with [input]. Do [specific steps]. Check [result]. If [failure], do [next action].

Example:

Before sending a report for approval, attach the source for each important number, name the reviewer and identify the exact version. If the source is missing, leave the claim unresolved rather than asking the reviewer to guess.

The steps should be sufficient for the narrow task. Link to a fuller guide when prerequisites would make the post too long.

4. Report a result with its limits

Structure: Over [period], we observed [result] in [defined group]. We changed [intervention]. [Other factors] also changed. The next question is [uncertainty].

Say your support team changed how it answers billing questions:

In September, 31 of 212 billing tickets were reopened, against 58 of 230 in August. We changed one thing on purpose: replies now link to the customer's own invoice instead of the general billing article. We also hired a second support person mid-month, so faster replies may explain part of the drop. The next question is whether the rate holds in October, once the new hire is fully trained.

Do not fill this with plausible numbers generated by AI. If you cannot support the result, use a different template. A customer quote also needs its context and permission, and it does not replace measurement.

Include the denominator where it matters. "Three of ten participants completed the task" communicates something different from "three successful users."

5. Ask a question after contributing context

Structure: Here is [specific situation] and the tradeoff we see. We are considering [options]. What experience would help us decide?

Example:

A single onboarding guide makes the whole process visible, but role-specific guides may make the relevant steps easier to find. If you've tested both, what confused new users in each version?

Use a question you intend to read and act on. If you already have the answer, share it instead of pretending to solicit advice.

Arguments and corrections

6. Translate a polite phrase

Structure: When a [role] says "[polite phrase]", it usually means [plain meaning]. Add one or two more pairs from the same setting. End with the question that gets the buyer to say what they mean.

Say you sell a compliance tool to heads of finance and run most discovery calls yourself:

When a head of finance says "send me some information", on my calls it has usually meant the problem isn't painful enough yet to spend a meeting on.

Two more I hear often. "We'll need to involve procurement" has often meant nobody has agreed to own the purchase, so I ask who would sign it. "The timing isn't right" has tended to mean another project already has the budget, and I ask which one.

After any of the three, I ask about the cost of waiting: "What happens if this is still unsolved in June?" A specific answer tells me the problem is real enough for a second call. It tells me nothing yet about budget or who signs.

Use phrases you hear often enough that readers will recognise them. Made-up ones fall flat. Keep the tone fond and do not mock buyers. The question at the end is what makes the post useful.

7. Swap an outcome goal for an input goal

Structure: For [audience], [popular target] is out of reach in [period]. What is within reach: two to four moves and what each produces. The time it costs. Then restate the goal as a weekly input the reader controls, and say which method to pick over its alternative.

Say you coach founders of seed-stage B2B companies who are starting on LinkedIn with about 300 connections:

Starting from 300 connections, 10,000 followers by summer would need growth you can't control, and chasing it pulls you toward posts written for strangers.

Here is what you can control in the next 12 weeks:

• Three posts a week about problems buyers raise on your calls. That's 36 posts and a record of which topics get replies.
• Ten considered comments a week on posts by people you'd like as customers. About 120 comments, each a reason for them to look at your profile.
• One message a week to someone who replied to you, asking about their work. Twelve messages. Count separately how many become conversations.

Time the first two weeks before you commit to all twelve. Then set the goal as the inputs (3 posts, 10 comments, 1 message, every week) and count the conversations that come of it each month. If you only have time for one of the three, start with the comments, since they reach buyers on posts that already have readers, and check after a month whether they led anywhere.

The totals in the middle only multiply the plan out over twelve weeks. They say nothing about how many replies or conversations will follow, so do not promise what the inputs will produce in followers, leads or revenue unless you have data from people in the same position.

8. Call out one audience and carve out the exceptions

Structure: For [audience] who [situation]: describe the practice they avoid as it really is. Say what skipping it costs. Name the readers for whom the advice is wrong and tell them to carry on. Give everyone else one first step.

Say you run a small agency that does customer research for B2B companies:

For founders selling to fewer than 500 possible accounts:

A customer interview can be a 30-minute call where you ask someone how they handled the problem last time. You don't pitch, and a handful of questions is enough.

Skip them and your website, posts and sales deck describe the problem in your words, which leaves buyers to translate.

If you already have a product team running interviews every week and sharing the notes, this isn't for you. Carry on.

Everyone else: book two calls this week with customers who signed in the last 90 days, and ask what they used before you.

The carve-out is what makes a firm recommendation fair. Address a role. "For founders who feel overwhelmed" presumes something you cannot know. Finish on the step rather than a request to follow you.

9. Take aim at a practice

Structure: [Practice] is standard in [market]. List what it does in practice, each with its effect on the customer. Concede what is reasonable about it. Name the part you do not accept, say why, and propose a better default.

Say you sell expense software to finance teams and keep reading auto-renewal clauses in the contracts they ask you to replace:

Auto-renewal with a 90-day notice window is common in the software contracts our customers send us.

What it does in practice:

• In the contracts we've seen, the notice date falls 90 days before renewal, usually before the customer has started thinking about it.
• Missing it by a day commits the customer to another full year.
• The reminder, if there is one, goes to whoever signed, and that person may have left.

Some of this is fair. Vendors plan headcount around renewals, and a notice period gives them time.

What we don't accept is the length. For a vendor our size, 30 days is enough warning, and it puts the customer's decision close to the renewal itself. Our contracts use 30 days, and we email the account owner and the finance contact 45 days before renewal.

Keep the target a practice, never a person. Name a company and the replies tend to be about that company's reputation rather than the clause. End on the default you propose. A closing "Is this acceptable?" invites a pile-on and adds nothing.

Teaching

10. Teach a named principle through one example

Structure: [Principle], in one line. Show it working in one example the reader can check. Explain the mechanism. Say how to use it in the reader's work, and where it stops working.

Say you run onboarding at a project tool for agencies:

The IKEA effect: people value things more when they built them. Michael Norton, Daniel Mochon and Dan Ariely described it in a 2012 paper, after studies in which people assembled IKEA boxes, folded origami and built Lego sets.

The detail worth noticing: the effect held only when people finished what they built. When they built something and then destroyed it, or failed to complete it, the effect went away.

The studies were about boxes, paper and bricks, not software, so applying them to onboarding is a guess. Ours is that a team which builds its first project template in the first session, even a rough one, will value the product more than a team that imports one of ours.

We're testing it by asking half of new teams to build one small thing they can finish in a sitting, such as a project with three tasks, and comparing how each group rates the product after a month. We'll also look at how many are still active, though that measures something else.

Use a principle with research behind it and link to the study (Norton, Mochon and Ariely, Journal of Consumer Psychology, 2012). Coining a name for an ordinary idea is the usual way this template goes wrong. Leave out any percentage you saw on a slide unless you found the study it came from.

11. Apply one source to your field

Structure: Name the source first. Its main rules, each translated into the reader's field with an example. Why it holds up. The one rule to start with.

Say you write the help centre for a payroll tool used by small businesses:

A useful guide to writing help articles was written for UK government websites: GOV.UK's guidance on using clear language.

Its rules, translated for a payroll help centre:

1. Try to split sentences over 25 words. Our "run payroll" article had a 61-word sentence about tax codes. It's now three.
2. Keep paragraphs to five sentences at most. Each step in a procedure now gets its own short paragraph.
3. Explain a specialist term the first time you use it. "Gross-to-net" gets one line of explanation, on first use, in every article.
4. Use "must" for legal requirements and "can" for options. We'd been writing "you must enable notifications". Now it says "you can".
5. Use the words your users use. Our help-centre search log had "payslip" far more often than "earnings statement", so the articles now say payslip.

We chose it because it is written for everyone who needs the content, including people who struggle with complicated language and people whose first language isn't English. Our customers include both.

Start with rule 4. It's the quickest to apply, and it stops ordinary settings from sounding like legal duties.

Name the source in the first line and link to it (GOV.UK: use clear language). Paraphrase, and never put words in the author's mouth. The template is worth most when the source comes from outside the reader's field, so they would not have found it themselves.

12. Map goals to the smallest real action

Structure: One line on how preparation can delay the work. Three or four goal-to-action pairs, each worded differently. A plain principle that ties them together.

Say you advise first-time founders on early sales:

A lot of early sales preparation is a polite way of not selling yet.

To learn how buyers describe the problem, have five calls where you ask about their last attempt to fix it. To prepare for objections, send the proposal to someone who might say no and write down what they push back on. For pricing, quote a number on the next call and see how they react. The sales deck can wait until you've given the pitch out loud ten times without one.

After those calls you'll know which objections keep coming up, and that tells you which course, if any, is worth paying for.

This is the riskiest template on the page. It tempts you to repeat one sentence frame four times and finish on a saying. Vary how each pair is written, as above, and end on a plain statement. It often works better as one section of a longer post.

13. Describe the stages of a hard habit

Structure: Starting [activity] costs [small cost]. Keeping it going for [period] costs [real cost]. Name what it has to produce before it pays back. Say what gets people through the middle.

Say you run the customer newsletter for a B2B analytics company:

Starting a customer newsletter takes an afternoon: a template, a list, a first issue.

Sending it every month for a year is a different job. The easy topics run out after the first few issues, and from then on each one needs a customer, a number or a product change worth explaining.

The part that pays comes later, when customers forward issues to colleagues and reply with questions you can answer in the next one. Nobody can tell you in advance how long that takes.

What has kept ours going is a shared note where support adds customer questions as they come in. Some months it has ten, some months one, and either way the next issue starts from something a customer asked.

Three stages written in the same rhythm read as a formula. Make each stage say something new about the work, and put the weight on what gets people through the middle. Avoid starting a sentence with "most people" unless you can show the count.

14. Lay out a restart plan

Structure: If I had to [reach a first result] from zero today, this is the order. Numbered steps, each with the reason it comes where it does. What you would skip, and until when.

Say you built and sold a bookkeeping software company and now advise others in that market:

If I had to find the first 10 paying customers for a bookkeeping tool from zero today, this is the order:

1. Pick one kind of business, say independent dental practices, because their books look alike and their owners talk to each other.
2. Do the bookkeeping for three of them by hand for a month, in spreadsheets, to learn which reports they ask for.
3. Build only what replaces the manual work you found most tedious in step 2.
4. Ask those three to introduce you to two practices each. Not every introduction will lead to a meeting, but the ones that do start with someone who has heard of you.
5. Charge from the first invoice, including the three from step 2 once their month is up.
6. Keep a list of who introduced whom and which meetings became customers. If introductions run out before you reach ten, the list shows which kind of practice to approach cold.

What I'd skip until there are ten paying customers: a website beyond one page, ads, and any integration nobody has asked for.

The order is the point, so give the reason for each position. Keep the skip list honest: if you would in fact build the website first, say so. This works as text or as a document post with one step per page.

Curation and commentary

15. Digest one expert's published playbook

Structure: [Named person] has [credential you can check]. One line on their approach, from [specific source]. Three to five points from that source, paraphrased and numbered. A link to the source.

Say you write for founders of very early B2B startups:

Paul Graham co-founded Y Combinator in 2005. His 2013 essay "Do Things that Don't Scale" argues that early growth has to be done by hand. Four points from it:

1. Don't wait for users to find you. Recruit them yourself, one at a time.
2. Give your first users more attention than seems sensible. A small company can, and a large one can't.
3. His examples: Airbnb's founders went door to door in New York to recruit hosts and improve their listings, and Stripe's founders set new users up on the spot instead of sending a link.
4. Do by hand the work you plan to automate later, so you learn what the automation has to do.

The full essay is at paulgraham.com/ds.html.

Every point must trace to the named source (the essay). If you add your own view, say where the paraphrase ends. Check the credential at its origin: this one comes from Graham's own bio page.

16. Do the maths on a worrying headline

Structure: [Development that sounds bad]. The numbers behind it. The worry, stated once. Your answer, with the arithmetic that shows what the reader needs. A practical next step.

Say you sell a compliance tool for €900 a month to mid-sized logistics firms, and a well-funded competitor has just launched a free tier:

A competitor launched a free tier this week, and three customers have asked what it means for us.

Their free tier covers one site and five users. Our customers run four sites on average, with about 40 users each.

The worry is that a free option will pull customers away from a paid one.

None of our current customers would fit inside it. Our smallest runs two sites with 18 users. The free tier will probably win some of the single-site firms we used to pitch, and we should expect that.

We also don't need the whole market. At €900 a month, €1 million a year is 93 customers, and our list of multi-site firms that need an audit trail has 1,400 names. The list is about fifteen times what we need. It says nothing yet about how many will buy, or how fast.

So this month we're demoing a multi-site audit, in 20 minutes, to the 40 firms on that list that run five or more sites.

The arithmetic must be right and its inputs stated, because readers will check it (€900 × 12 is €10,800 a year, and €1,000,000 ÷ €10,800 rounds up to 93). State the worry as a plain sentence rather than asking it and answering yourself, and say what the numbers do not settle. Source any number about the wider market.

17. Take apart examples worth studying

Structure: A cover that names N artifacts of one kind and who they are for. One page per artifact: the artifact, what it does, why it works. A last page with the pattern across all of them.

Say you lead support at a B2B invoicing tool and want to show new hires what a good reply looks like. As a document post:

1. Cover: "Five support replies that closed the ticket in one message. From our own inbox, customer details removed."
2. A failed bank sync. The reply opens: "Your bank feed is fixed. Reconnect it once under Settings, Bank feeds, and the missing days will come in." The cause comes after, so the customer can stop reading once the problem is solved.
3. A duplicate invoice. "Open the second invoice and choose Void, the button circled in the screenshot below." The screenshot replaces a chain of "click Settings, then Billing, then" instructions.
4. A refund refusal. "We can't refund the annual plan after the first 30 days, but we can stop it renewing, and I've done that for you." The no comes first, then the one option the customer does have.
5. A feature request. "Recurring credit notes aren't planned this year. For now, duplicating last month's note takes two clicks, shown here." Nothing is promised that the roadmap doesn't hold.
6. A currency question. "Invoice INV-0412 is in euros because your customer record is set to EUR. Change it under Customers, Currency, and the next invoice will be in pounds." Quoting the customer's own invoice shows the answer is about their case.
7. Last page: each reply puts the answer or the decision in its first sentence. Start there when you rewrite your saved replies.

Every page needs a new artifact and a new reason. A document whose pages restate the cover is the common failure. Credit whoever made the work you show, here the support staff who wrote the replies, with their agreement.

Results and company news

These four report something that happened to a company: yours, or a customer's with permission. They need real figures with dates.

18. List what you skipped and what you did instead

Structure: Open on the result. The commonly recommended things you did not do. The few things you did, with reasons. What the reader can take from the difference.

Say you run a six-person developer tools company that reached 200 paying teams in its first year:

We reached 200 paying teams in our first year without a sales team, an ads budget or a product directory launch.

What we did instead:

• Wrote the docs before the landing page, because developers decided from the docs.
• Answered every support email within a working day, from the founders, for the first 100 customers.
• Put the price on the website from day one, so nobody had to book a call to find it.
• Kept a public changelog and posted to it every Friday, even in weeks when the only change was a bug fix.

The one worth copying is the support. It cost about an hour a day, and most of what we built in the second half of the year came out of those emails.

Open on the result. A run of denials first ("No ads. No sales team. No launch.") only delays it. Only list skipped practices your readers are really told to follow. Leave off the closing line about every company being different.

19. Tell a customer's rise in the third person

Structure: Where they are now. Where they started. The obstacle. What they did. A setback. Today, in dated numbers. What explains it, and how the reader can use it.

Say you sell route planning software, and a customer, a 40-person courier firm, has agreed to be written about and has given you its figures:

One of our customers, a 40-person courier firm, now delivers about 3,000 parcels a day. In 2023 it was eight drivers and a whiteboard.

Same-day orders were the obstacle. Every one that came in after 10:00 meant redrawing the routes by hand, and by noon the whiteboard was wrong.

First they stopped taking same-day orders after 11:00. Then they moved planning into software and replanned twice a day, at 07:00 and 12:00.

That held until they won a pharmacy contract with one-hour delivery windows. A van carrying pharmacy orders couldn't wait for the noon replan, so they ran the pharmacy routes as a separate fleet with its own planner.

In September 2026 they ran 31 vans, and one delivery in forty was late. In their first month with us it was one in twelve.

Their operations lead puts most of the change down to the cut-off and the separate fleet, more than to the software. If your schedule keeps breaking at the same point, find the orders that break it before you change tools.

Every fact about a real company needs a source or the company's sign-off, and figures need a date. Tell it plainly. The cliffhanger one-liners these posts often use add drama and no information, and the lesson has to follow from the facts you gave.

20. Announce a launch that slipped

Structure: The date, the product and who it is for. If the date moved, how late it is and the causes users will notice, with what changed. What it does now. Where to see it, with date, time and time zone.

Say you run a small company that makes a contract review tool for in-house lawyers, and version 2 is shipping late:

On 3 December we release version 2 of our contract review tool, for in-house lawyers who check supplier contracts against a playbook.

It's six weeks later than we said. Three things went wrong:

• The clause matcher missed renamed headings, such as limitation of liability filed under "Liability cap". We rebuilt it to match on the clause text.
• Two pilot teams needed their own playbooks in the tool, so we added playbook import.
• The redline export broke tracked changes in older Word files. We now test on files back to Word 2010.

It now flags clauses that depart from your playbook, suggests your fallback wording, and exports a redline your counterparty can open.

We're demoing it on 3 December at 16:00 CET. The link is in the first comment.

Lead with the date and the problem it solves, and leave out how the team feels. Keep a problem on the list only if it changed what users get, as each of the three here did. Any offer with a deadline needs a real date.

21. Mark a milestone by the method behind it

Structure: The milestone and its date. Why this one matters more than an earlier one. The method that produced it. Two concrete changes and their effect. One next step for readers who want the same.

Say you run a hiring platform for restaurants that has just passed 1,000 paying venues:

We passed 1,000 paying venues on 4 November.

We passed 500 two years ago through a reseller deal. The deal ended a year later, and about a third of those venues left with it.

Since then, 610 of our new venues signed up with a referral code from another venue. Two changes came just before referrals picked up: the referral credit now pays out only after the new venue makes its first hire, and every welcome pack has a printed card for the manager to pass on. We can't separate the effect of the two yet.

If you're testing a referral reward, try paying it on the new customer's first success rather than at sign-up, and check whether those customers stay longer.

A milestone post turns into a humblebrag fast. Keep it about the change of method, and use one call to action at most.

Lighter posts and the close

22. Parody a LinkedIn convention

Structure: Borrow a familiar LinkedIn format. Swap in a mundane payload. Add one line with the real point, if there is one.

Say you run a small accounting firm whose clients know your sense of humour:

I'm humbled to announce that after 14 months, three accountants and one very long call with the tax office, a client's 2024 VAT return has been accepted.

I couldn't have done it without the client's shoebox of receipts and the hold music, which I now know by heart.

If your 2025 receipts are also in a shoebox, January is a good month to send them.

The joke depends on readers recognising "humbled to announce", which is the only reason the phrase is here. Keep parody short, aim it at the convention, and never at a named person who posts that way.

23. Close with a single offer

Structure: One sentence linking the post to the resource. What the resource is, concretely, and who it is for. Where to find it.

Say this follows the input-goal post in template 7, and you have built a spreadsheet to go with it:

The weekly plan above is the first tab of a longer worksheet. The 12-week LinkedIn log is a free spreadsheet with a row per week for posts, comments and conversations, and a tab that totals them by month. It's for founders who want to track their own effort instead of their follower count. The link is in the first comment.

Use one offer per post and match it to the topic. Requests to follow, repost or comment are asks for reach and give the reader nothing. If the post ends on an open thought, put the offer after it or in the first comment, so the post itself still finishes on the idea. Most posts need no offer at all.

Review the batch, not only each post

A set of individually sound templates can still produce repetitive content. If a month of posts uses template 7 four times, put the four openings, examples and endings side by side before any of them goes out. Check that each post adds a different example, decision or answer.

The AI-slop review guide helps inspect a batch. The hook guide helps make the opening match the substance, and the LinkedIn writing framework shows how to test the claim inside any of these templates before you write it.