# One source, three complete treatments

Companion to the content distribution guide. All treatments use an original fictional approval conversation. The LinkedIn post was not posted; the short is a proposed treatment and no film was produced. These texts do not report client work or campaign results.

## Choose the insight and its boundary.

A distribution plan starts before the export list. Identify the idea worth carrying, who needs it and what different encounters should help them do. Ten derivatives can repeat the same explanation ten times; three considered treatments can serve three different situations.

The source here is the [original fictional approval conversation ](https://machinehouse.media/resources/podcast-trailer/source-transcript.txt). Its insight: a manual workaround may carry a decision the software has not understood. Its boundary: this invented scenario does not establish measured savings or a rule that all manual processes should remain. Every treatment below retains that scope.

Choose channels from audience behaviour and your ability to make good native work. An owned page gives the argument a durable destination. A social post introduces it in a feed. A short film can make the confusing object visible. A newsletter could instead serve readers who already want a considered return visit. You do not need every channel for every idea.

## Owned essay: explain the decision.

Completed illustrative treatment. Its job is explanation for someone willing to read the argument and its counterexample. The lead starts with the apparent inefficiency, then develops the responsibility problem. This is original teaching copy, not a report of actual client work.

### What the phone call knows

A useful workaround looks inefficient from the outside.

Consider an invented print-shop scenario. An operator receives a customer’s “looks good” message, then calls for confirmation before printing. A software team might see a redundant step: approval has arrived, so why is the operator still on the phone?

There are two files called final. The person who commented can check the wording, but may not have permission to release the job. The call connects a particular version to a person who can accept the consequence of printing it. The software has recorded an action while the operator still needs a decision.

That distinction changes the product brief. A faster notification does not settle which file is approved. A more prominent tick does not give its author more authority. Before replacing the call, the team needs to know what information and responsibility it carries.

This does not mean preserving every manual step. If the same person owns the wording, version and release decision, adding three approvals would make a simple job harder. The right design depends on the actual responsibility map.

A small next test would name the release owner and the approved version, then observe a rush job and a late change. Does the operator know what they may print? Does a replacement file reopen the right decision? Those observations would help judge the repair. A tidy demonstration alone would not prove a faster business.

Before automating a workaround, write down the decision it currently carries. Then decide whether to remove the step, redesign it or keep it visible. The phone call may be unnecessary. First, understand what would disappear with it.

## LinkedIn: make the problem recognisable.

Completed illustrative treatment; not posted. The scene is compressed for a reader encountering it in a feed. Short paragraphs make the sequence legible; the final sentence offers a reason to continue into the essay. The fictional label remains in the post itself.

### A feed-native version

Two files called final.

A green tick.

And an operator still making a phone call before printing.

In this fictional product-design example, the call looks like an unnecessary step. But “looks good” can mean the wording is correct. It does not necessarily mean this person can authorise printing this version.

The tick records an action. The call settles a decision.

That is the question I would put in the product brief: what responsibility is this manual step carrying?

If one person owns the whole decision, keep it simple. If they do not, a faster notification will not resolve the missing authority.

Before removing a workaround, ask the person using it what they would otherwise be unable to decide.

The accompanying essay works through this example and a small test for the proposed repair.

If the destination is a newsletter: write for an existing reader returning to you. A subject such as “What the green tick misses” can introduce the same example; the first paragraph should explain why you are bringing it to this readership now. Keep the operator’s scene and the one-person exception, then offer the format or approval worksheet as the useful next step. Preserve the fictional label in the email itself. The fuller essay above can supply the argument, but remove website navigation and replace a public-comment invitation with a reply question: “Which manual step in your team still carries an unnamed decision?”

The LinkedIn treatment earns attention from someone who may not know you. The newsletter earns the next opening by being useful to someone who already chose to hear from you. Use the actual mailing-list permissions and editor, confirm links in a test email and set a realistic send date. A written treatment is not evidence that it was mailed or read.

## Short video: let the object explain it.

Complete proposed treatment; no film produced. The visual has a job that prose cannot perform as quickly: keep two versions visible while separating comment from release. Use original mockups, readable type, accurate captions and cleared audio. Do not imitate a real customer’s private chat.

| Proposed picture | Complete spoken script

| Show two recreated filenames, both “final”. Label the whole treatment as a fictional example. | Two files called final. Someone says, looks good. Why is the print operator still making a phone call?

| The two files stay visible. Introduce labels: wording, version, release. | Because those words can mean three different things. The wording is correct. This is the right version. Or you may spend money printing it. Those decisions do not always belong to the same person.

| Show a tick beside the comment; leave the release-owner field blank. | A green tick records that someone clicked. It does not tell the operator whether that person can release the job. The phone call is carrying the responsibility the screen has left unclear.

| Fill one version field and one release-owner field in a labelled mockup. | In this invented example, the next test would name the version and the person who can release it. Then observe what happens when the file changes or that person is away.

| End on a readable question, with captioned narration. | The lesson is not to add more approvals. It is to understand the decision before removing the step. What would someone be unable to decide if your workaround disappeared?

The script ends with a usable question, so the short makes sense on its own. Its destination can offer the fuller essay and worksheet. A clip pulled from an interview would require a different cut and source check; this is an original standalone script derived from the idea.