LinkedIn process explanation post template

When to use this template

Use this when a prospective client cannot see what happens between a brief and a deliverable. Choose one stage you can explain accurately. A process post demonstrates a method; a case study reports an actual project and its outcome. If you have not yet used the method, present it as a proposed approach rather than your established practice.

Gather these notes first

• The specific task or stage you are explaining.
• The material you need at the start.
• Two or three checks you actually make, including one decision that changes the path.
• A small invented example or an approved, anonymized example.
• The output and the work that still remains afterward.

A structure you can fill in

Replace each bracket with your own facts. Remove any sentence you cannot support; the structure should fit the work you actually did.

What happens when [task reaches you]?

I start with [input], rather than [premature action].

Here is the sequence:
1. [Check] — so we can decide [decision].
2. [Check] — if [condition], we [branch].
3. [Action] — producing [output].

A small example: [label the example and show the input].
That leads to [specific output or next decision], because [reason].

At this point we have [what is ready]. We still need [what is not finished].

[Question about the step readers want explained.]

Worked example

Fictional example: a messaging consultant demonstrates how they turn a vague homepage brief into a page outline. The notes and draft below are invented to illustrate the explanation; no client outcome or conversion improvement is claimed. Use your own experience when adapting it.

The notes behind the draft

Input

An invented brief says: “Show all our capabilities and get more enquiries.” The service is a handoff review for small agencies.

First decision

Which visitor situation should the page address? Choose a project with unclear ownership between teams.

Evidence check

The brief has a clear deliverable but no approved customer results. Explain the work without adding performance claims.

Output

An outline covering the situation, review steps, deliverable and scope boundary. Copy, design and testing are still to come.

The post built from those notes

What happens before I write a service homepage?

I start with the decision the page needs to help a visitor make. “Show all our capabilities” does not tell me that yet.

Here is the sequence:
1. Name the visitor situation. What is happening when this service becomes relevant?
2. Check the evidence. What can we explain or show, and which claims are still unsupported?
3. Outline the page around that decision before writing finished copy.

Take this invented brief: an agency adviser offers a handoff review, but the homepage currently lists every service they could provide.

I would start the outline with the moment work moves between teams and ownership becomes unclear. Then I would explain the review, the checklist it produces and what is outside its scope.

If there are no approved customer results, I would describe the deliverable. I would not add a claim that it reduces delays by a particular amount.

Now we have a page outline to discuss. We do not yet have finished copy, a design or evidence of how visitors will respond.

Which part of your service needs a clearer explanation before someone can decide whether it fits?

Why this version is useful

• The input is recognizable and the process ends in a named deliverable. The reader can follow the work between those points.
• The evidence check changes what can appear in the outline. It demonstrates judgment, rather than listing generic stages.
• The final boundary separates a completed outline from finished copy or measured visitor behavior.

Make the wording more specific

Too vague

Our proven framework takes you from confusion to clarity.

More useful

We turn the brief into an outline by agreeing on the visitor situation, checking the evidence and choosing the page sections.

Explain what someone can inspect at the end of the stage. Use “proven” only if you can say what was tested and what that evidence actually establishes.

Adapt it to your work

A recruitment adviser could show how a role description becomes an interview brief. A design agency could explain how requirements become a navigation sketch. Keep the demonstration to one stage, include the input and output, and show the condition that would make you take a different next step.

Check it before publishing

• Is the method something you use, or clearly labeled as an approach you propose to test?
• Can the reader identify the input, a meaningful decision and the output?
• Does the example show the process without exposing private client material?
• Have you distinguished the deliverable from an unmeasured business result?
• Would a reader understand what still needs to happen after this stage?

Read the draft aloud and replace wording you would not use in a conversation. The voice-brief builder helps organize your facts and writing preferences. When the wording is ready, use the free text formatter to add light emphasis and clean spacing.

After someone responds

If someone asks about a step, explain the decision behind it. If they describe their own project, check the relevant context before suggesting the whole process. Interest in your method does not by itself establish fit for your service.

Turn a useful explanation into a relevant conversation.

Choose a different post’s job

• LinkedIn case study post template — Explain a project decision and what changed.
• LinkedIn lesson learned post template — Teach one change in how you work.
• LinkedIn client question post template — Answer a question a potential buyer already asks.
• LinkedIn service introduction post template — Explain who a service helps and what the work includes.
• LinkedIn resource announcement post template — Help the right reader use a resource you have finished.