Home Framework Library PAR

PAR

Problem-Action-Result

The repair story — where the diagnosis is the evidence, not the fix.

People & Teams Pro Framework 3 Steps

What is PAR?

PAR is three slots: Problem, Action, Result. Like CAR it is a compressed member of the STAR family, and like CAR the whole of its character sits in the first slot: Problem insists that something was actually wrong.

That insistence narrows what PAR is for, usefully. A Challenge can be a goal or a stretch; a Problem is a thing that was broken, and PAR is therefore the framework for repair stories — the inherited mess, the process that kept failing, the relationship that had gone wrong. Which brings out the property that makes PAR worth a page of its own: in a repair story the interesting part is not the fix. Anyone can add an index. The diagnosis is the evidence. A junior engineer writes "I added an index"; a senior one writes "I read four months of logs before changing anything and found all four failures shared one cause". Same fix, completely different claim — and a prompt that does not ask for the diagnosis will get you the junior version every time.

Best used for
Problem-solving narratives troubleshooting stories fix implementations resolution stories

Where PAR Came From

Career-coaching practice, no author of record

PAR has no documented inventor. It belongs to the résumé-writing and career-coaching tradition alongside CAR, and both circulate as simplifications of the behavioural-interview STAR structure that came out of industrial and organisational psychology in the 1970s. Any page naming a creator is guessing.

The family differs only in its second slot

STAR has Task, SOAR has Obstacle, CAR has Challenge, PAR has Problem. Every one of them keeps Action and Result. That is not four theories, it is one structure with an argument about what should precede it — and the argument matters, because the second slot decides which stories the framework can hold.

Where PAR is genuinely the right pick

Use it when the honest first sentence of your story is "this was broken". The Problem slot gives you licence to describe the damage — the failures, the manual workarounds, the customers who complained — which CAR's single compressed clause has no room for and which a Task-based framing quietly discourages. And unlike CAR, PAR is usually written at paragraph length, so there is space for how you worked it out.

The 3 Slots, One at a Time

Each slot is a decision. Leave it out and the model still makes it — just without you.

P
Problem
What was broken, how long it had been broken, and who was absorbing the cost.

Give it duration and a victim. "The billing run failed" is an incident; "it had failed on the last day of the month for four consecutive months, and finance chased 3,000 invoices by hand each time" is a problem. Include the ownership vacuum if there was one — inherited, unowned, author left — because that is context nobody can accuse you of engineering.

Weak There was an issue with our billing system.
Strong The billing run had failed on the last day of the month for four consecutive months. Each failure meant 3,000 invoices went out late and finance chased them by hand. Nobody owned the job; the original author had left.
A
Action
The diagnosis first, then the fix — and the fix is the less interesting half.

The slot that carries the whole framework. Show how you found the cause, including what you ruled out, because ruling things out is the difference between diagnosis and luck. Then the fix, and ideally the second-order fix — the check, the runbook, the owner — since "I stopped it happening again" is a different claim from "I made it stop today".

Weak I fixed the query and it works now.
Strong I read four months of logs before changing anything and found all four failures shared one cause. I added the index, then a pre-run check that fails loudly a day early instead of silently on the night, wrote the runbook that did not exist, and put my name on the job so it had an owner.
R
Result
What has happened since — with the modesty the evidence supports.

Prefer elapsed evidence to a claim: "five clean runs since" beats "the problem is solved". And the strongest closing detail in a repair story is usually about the system rather than the outcome — somebody else using your runbook while you were away proves more than any metric about how permanent the fix is.

Weak The problem is now permanently resolved.
Strong Five clean runs since. The pre-run check has caught two problems a day ahead, both fixed before anyone noticed. The runbook has been used once by somebody else while I was on leave.

One Task, Before and After

The task: A repair account for a performance review and a promotion case. Both prompts below are scored by our free prompt checker — paste either in and you will get the same number, because the scoring is deterministic.

20 Without PAR · weak
Write about a problem I fixed at work.

Seven words. You get a tidy three-paragraph story in which the problem is vague, the fix is heroic, and a 40% improvement appears from nowhere.

92 With PAR · strong
Write a Problem-Action-Result account of a fix, for a performance review and a promotion case.

Problem: Our billing run had failed on the last day of the month for four consecutive months. Each failure meant 3,000 invoices went out late, finance chased them by hand, and two enterprise customers had raised it in writing. Nobody owned the job - it had been inherited twice and the original author had left.

Action: I read four months of logs before changing anything and found all four failures shared one cause, a timeout on a report query that grew with the customer count rather than anything to do with month-end. I added the index, then added a pre-run check that fails loudly a day early instead of silently on the night, and wrote the runbook that did not exist. I also put my name on the job so it had an owner.

Result: Five clean runs since. The pre-run check has caught two problems a day ahead, both fixed before anyone noticed. Finance stopped the manual chase. The runbook has been used once by somebody else while I was on leave.

Write 350 to 400 words in three short paragraphs, one per element, first person and past tense. It will be read by my manager and a promotion panel who do not know the system and who care about judgement rather than technique.

Weigh which detail here is actually the evidence of seniority before you write - reading four months of logs before touching anything is a different claim from fixing a query, and the second is what a junior engineer would lead with.

Give the Action paragraph the most space, and make sure it shows the diagnosis and not just the fix. For example, open in this register:
```
The billing run had failed on the last day of the month four times running, and nobody owned it.
```
Ensure every number traces to the three sections above, and keep this to the one problem. The account must show what I ruled out as well as what I found, since that is the difference between diagnosis and luck. Do not blame the previous owner or the person who left, do not claim the outcome is permanent, and do not invent revenue impact, customer names or time savings that are not stated.

Ninety-two. The instruction that changes the output most is the one about seniority: without it the model leads with the index, which is the least impressive true thing in the account.

Ninety-two, and nothing checks whether the diagnosis survived the edit

One check is unreachable, and the two things that decide whether a repair story lands are unmeasured:

Role0 / 8

No persona slot, and correctly so — this is your own account of your own work, and it will be read by people who can ask you about it. A persona writes sentences you cannot stand behind.

Whether the diagnosis is thereunscored

The whole argument of the framework, and invisible to scoring. "I added an index" and "I read four months of logs before changing anything, then added an index" describe the same action and make completely different claims about you. Only the second is evidence of judgement, and no rubric can tell them apart.

Whether it is honestunscored

Like SOAR, this is a document that gets cross-examined — by a manager who was there, or a panel who will ask. An invented figure costs more here than in any piece of copy.

The line worth taking from this page into any repair story: say what you ruled out, not only what you found. It is the cheapest available demonstration that the fix was diagnosis rather than luck, it takes one clause, and almost nobody includes it.

Copy-Paste Prompt Template

Replace the bracketed placeholders with your specific details.

Problem: [What was broken, HOW LONG it had been broken, who was absorbing the cost, and whether anybody owned it]

Action: [The DIAGNOSIS first — how you found the cause, and what you ruled out]
[Then the fix. Then the second-order fix: the check, the runbook, the owner]

Result: [What has happened since, bounded by evidence — "five clean runs", not "permanently resolved"]

[Length and reader. Give the Action paragraph the most space]
[Weigh which detail is the evidence of seniority before writing — it is rarely the fix]
[No invented impact. Describe the ownership vacuum, never blame the person]

When PAR Fits — and When It Does Not

Reach for it
  • Performance reviews and promotion cases built on something you repaired.
  • Stories where you inherited a mess rather than choosing a project.
  • Incident write-ups aimed at people, as distinct from formal post-mortems.
  • Interview answers about troubleshooting, where the diagnosis is the point.
  • Any account where "this was broken" is the honest first sentence.
Use something else
  • Achievements that were not repairs — a launch or a growth story wants CAR.
  • CV bullets. PAR runs to paragraphs; use CAR when the space is one line.
  • Behavioural questions about conflict or resistance — SOAR's Obstacle slot fits better.
  • Problems you caused. PAR describes inheriting damage, and the framing shows if it is false.
  • Marketing and customer stories. Use BAB, which tells the same arc about somebody else.

10 Ready-Made PAR Prompts

Every prompt below was produced by the Frompting generator with PAR selected — not written by hand for this page. Each is scored by our prompt checker; the median is 86/100. Click one to open it, then copy.

Fixing a recurring production outage 84
You are a seasoned incident‑response engineer tasked with writing a concise narrative that explains how you resolved a recurring production outage.

Your account should be organized as a clear, chronological story that first outlines the underlying issue, then details the specific steps you took to diagnose and remediate it, and finally describes the measurable outcome of your actions.

Write the narrative for **[AUDIENCE: e.g., hiring manager, technical blog readers, internal post‑mortem team]** and keep the total length between 250 and 350 words.

**Quality criteria**
1. Accurately convey the technical context and the root cause without assuming prior knowledge.
2. Highlight the concrete actions you performed, including tools, commands, or processes used.
3. Quantify the result (e.g., downtime reduction, error rate drop) and note any lasting improvements.

**Boundary** – Do not include unrelated projects, personal opinions, or speculative future work.

If any essential details are missing, explicitly state your assumptions and ask up to three clarifying questions before finalizing the narrative.
158 words · scores 84/100 solid
A customer escalation that ran for months 76
You are a seasoned customer‑service professional tasked with crafting a concise narrative that recounts how a prolonged customer escalation was finally resolved.

The story should be written for [AUDIENCE: specify who will read this, e.g., senior management, training participants, marketing materials] and limited to 300 words.

Begin by describing the situation that triggered the escalation, including the key pain points that kept the issue open for months.
Next, detail the specific steps you took to investigate, coordinate with internal teams, and implement a solution, highlighting any troubleshooting techniques or communication strategies used.
Conclude with the outcome of your actions, quantifying the impact where possible (e.g., reduction in complaint volume, restoration of customer trust, financial benefit) and noting any lasting improvements introduced.

Quality criteria:
1. Clear, chronological flow that naturally guides the reader through the three sections.
2. Use concrete details and measurable results; avoid vague generalities.
3. Maintain a professional yet engaging tone appropriate for the intended audience.

Exclude any unrelated background information or speculative future plans.

If any essential details (such as the industry context, the role you played, or the specific metrics of success) are unknown, state your assumptions explicitly and ask up to three clarifying questions before finalizing the narrative.
202 words · scores 76/100 solid
Repairing a broken onboarding process 86
You are an experienced process improvement consultant.
Your task is to craft a concise, step-by-step narrative that explains how to repair a broken onboarding process for **[TARGET AUDIENCE]: specify the primary users or stakeholders (e.g., new hires, customers, partners)**.

Begin by outlining the key issue that made the onboarding ineffective, then detail the concrete actions you took to diagnose and resolve the problem, and finally describe the measurable outcome achieved after the fix.

Write the response in plain prose of **375-495 words**, using short paragraphs for each part of the story. Ensure the narrative:
- Clearly identifies the root cause and its impact.
- Lists specific troubleshooting steps, tools, or methods employed.
- Quantifies the result (e.g., time saved, satisfaction increase) or states the qualitative improvement.

Quality criteria:
1. Logical flow that naturally moves from issue to action to outcome.
2. Use concrete details and avoid vague generalities.
3. Keep the tone professional yet accessible for **[READERS’ EXPERTISE LEVEL]: indicate if they are beginners, managers, or technical staff**.

Exclude any mention of frameworks, acronyms, or internal methodology names. If any essential detail is missing, state your assumption and ask up to two clarifying questions before finalizing.
195 words · scores 86/100 strong
Resolving a data quality problem 64
You are a data-quality specialist tasked with crafting a concise narrative that demonstrates how you identified and resolved a data-quality issue.

The story should be written for [AUDIENCE: specify the intended reader, e.g., hiring manager, client, technical team] and be under 450 words.

Begin by describing the specific data-quality problem you encountered, including the context (e.g., type of data, source, impact on business decisions).

Next, detail the concrete actions you took to diagnose and fix the issue, mentioning any tools, techniques, or processes employed.

Conclude with the measurable result of your intervention, highlighting improvements such as error-rate reduction, data-pipeline stability, or decision-making accuracy.

**Quality criteria:**
1. Clear, logical flow that naturally moves from problem to action to outcome.
2. Use concrete, quantifiable details where possible; mark any estimates as approximate.
3. Maintain a professional yet engaging tone appropriate for the specified audience.

**Boundary:** Do not include unrelated project experiences or generic advice on data quality.

If any of the required details are unknown, state your assumption and ask up to three clarifying questions before proceeding.
173 words · scores 64/100 workable
Repairing a failing supplier relationship 79
You are a seasoned supply‑chain professional tasked with crafting a concise narrative that explains how you turned around a deteriorating supplier relationship.

Write a clear, step‑by‑step account that first outlines the specific challenge you faced, then details the precise actions you took to address it, and finally describes the measurable outcome of those actions.

The narrative should be written for [AUDIENCE: specify who will read this story, e.g., senior management, potential clients, or a hiring committee] and be no longer than 300 words.

**Quality criteria**
1. Clearly identify the root cause of the supplier issue and why it mattered to the business.
2. Describe concrete actions you implemented, including any negotiation tactics, process changes, or communication strategies.
3. Quantify the result with at least one metric (e.g., cost reduction, delivery improvement, risk mitigation) or a specific business benefit.

**Boundary** – Exclude any confidential contract details or proprietary data; keep the focus on your problem‑solving approach and outcomes.

If any of the following details are unknown, state your assumption and proceed, or ask for clarification:
- [INDUSTRY: the sector in which the supplier operates]
- [SUPPLIER TYPE: raw materials, components, services, etc.]
- [DURATION OF ISSUE: how long the relationship was failing before intervention]
- [KEY PERFORMANCE METRIC: the primary metric you improved, such as on‑time delivery rate]
219 words · scores 79/100 solid
Closing a compliance gap found in an audit 86
You are a compliance specialist tasked with drafting a concise narrative that explains how a compliance gap identified during an audit was closed.

Write a clear, professional piece of approximately 300 words that walks the reader through the situation, the steps taken to address the gap, and the outcome achieved.

Structure the content in three logical parts: first describe the gap and its implications, then detail the specific actions implemented to remediate it, and finally summarize the results and any lasting improvements.

The narrative is intended for [AUDIENCE: e.g., senior management, regulatory reviewers, internal audit committee].

Ensure the writing is factual, uses appropriate compliance terminology, and highlights the effectiveness of the response.

Quality criteria:
1. Accurately conveys the nature of the gap and its risk.
2. Clearly outlines the remediation steps with enough detail to demonstrate thoroughness.
3. Shows measurable or observable results, such as restored compliance status or risk reduction.

Exclude any speculative data or unverified claims; only include information that can be reasonably assumed or is typical for such scenarios.

If any essential details (e.g., industry sector, specific regulation, timeline) are unknown, state your assumptions explicitly and ask up to three clarifying questions before finalizing the narrative.

Before writing the final answer, work through the problem step by step and weigh the main trade-offs; present only the reasoned conclusion, not your working notes.
223 words · scores 86/100 strong
A team that kept missing deadlines 92
You are a seasoned organizational consultant tasked with crafting a concise narrative that explains how a team repeatedly missing deadlines was turned around.

Your response should be a clear, step‑by‑step story written for [AUDIENCE: e.g., senior leadership, HR professionals, project managers] that demonstrates troubleshooting ability and practical change management.

Write the narrative in roughly 300 words, using short paragraphs to separate each stage of the story. Ensure the following quality criteria:
1. Clearly identify the underlying cause of the missed deadlines.
2. Detail the specific interventions implemented to address the cause.
3. Show measurable improvement after the interventions, using concrete indicators (e.g., on‑time delivery rate, cycle time reduction).

Exclude any speculative personal opinions or unrelated anecdotes; focus solely on the turnaround process.

If any essential details are unknown, insert a placeholder in the format **[PLACEHOLDER_LABEL: brief hint]** (e.g., [TEAM SIZE: number of members]).

Before delivering the final narrative, state any assumptions you are making and ask up to three clarifying questions to fill critical gaps.
168 words · scores 92/100 strong
A billing error affecting many customers 91
You are a skilled technical writer tasked with crafting a concise narrative that explains how a billing error affecting many customers was identified, addressed, and resolved.

Write a clear, step‑by‑step account that first describes the nature and impact of the error, then details the specific actions taken to investigate and fix the issue, and finally outlines the outcomes for the customers and the organization.

The narrative is for [AUDIENCE: specify who will read this, e.g., customer support team, executive leadership, public blog readers]. Use a professional yet approachable tone appropriate for that audience.

Limit the total length to 300 words. Ensure the text:
- Clearly conveys the scope of the problem and its effect on customers.
- Describes concrete actions (e.g., data analysis, system rollback, communication steps).
- Highlights measurable results (e.g., error corrected for X customers, refunds processed, confidence restored).

Do not include any unrelated background or speculative details.

If any of the required details are unknown, state your assumptions explicitly and ask up to three clarifying questions before completing the narrative.

Quality criteria: factual clarity, logical flow, and a tone that builds trust with the intended readers.
193 words · scores 91/100 strong
Fixing a slow website 89
You are a seasoned web performance engineer tasked with writing a concise troubleshooting narrative about resolving a slow website.

The narrative should be written for [AUDIENCE: specify who will read this, e.g., technical team, client executive, blog readers] and must be under 720 words.

Structure the story in three sequential parts:

1. Begin by clearly describing the specific performance issue you encountered, including any measurable symptoms (e.g., page load time, Time to First Byte) and the context in which it occurred.
2. Detail the step-by-step actions you took to diagnose and fix the problem, naming the tools, techniques, and configurations used (e.g., profiling, code refactoring, CDN setup).
3. Conclude with the concrete results achieved, citing before-and-after metrics and the impact on user experience or business goals.

Quality criteria:
- Use precise technical terms where appropriate, briefly defining any that may be unfamiliar to the intended audience.
- Keep the language clear and engaging, varying sentence length to avoid a mechanical tone.
- Ensure the narrative flows logically from issue to solution to outcome without extraneous detail.

Exclude any speculation about unrelated site features, and do not mention the underlying framework or methodology by name.

If any essential details (such as the website’s platform, the root cause, or the performance metrics) are unknown, insert a placeholder in the format **[PLACEHOLDER_LABEL: brief hint]** and proceed.

If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue - do not ask for it and stop.
258 words · scores 89/100 strong
A long-running conflict between two teams 69
You are a seasoned organizational consultant tasked with crafting a concise narrative that illustrates how a prolonged conflict between two teams was successfully resolved.

The story should be written for [AUDIENCE: specify who will read this, e.g., senior leadership, HR professionals, or a broader employee audience] and must be under 405 words.

Begin by describing the underlying issue that caused the conflict, including the key symptoms and impact on collaboration and performance. Then detail the specific steps taken to address the problem, highlighting the methods, tools, and stakeholder engagements employed. Conclude with the measurable outcomes achieved, such as restored trust, improved workflow efficiency, or quantifiable performance gains.

Ensure the narrative is clear, engaging, and written in a professional yet approachable tone. Use concrete examples and avoid vague generalities.

Quality criteria:
1. Logical flow that naturally moves from issue description to actions taken to results achieved.
2. Inclusion of at least one specific metric or observable change that demonstrates success.
3. Language that is concise and free of unnecessary jargon.

Boundary: Do not include any proprietary company details or confidential information; keep all references generic or replace them with placeholders.

If any essential details (e.g., the names of the teams, the specific conflict triggers, or the exact results) are unknown, indicate them with clearly labeled placeholders in square brackets.

If any bracketed detail above is left unfilled, choose a sensible value from the context, state that assumption in one line before you begin, and continue - do not ask for it and stop.
250 words · scores 69/100 workable

Scores range from 64 to 92. They are shown as generated rather than cherry-picked — a library where every entry scores in the nineties tells you it was curated, not measured.

PAR vs the Alternatives

CAR Challenge, Action, Result

The nearest neighbour, and honestly very close. Challenge admits a goal or a stretch; Problem insists something was broken. CAR is normally written at bullet length, PAR at paragraph length — which is often the more practical way to choose between them.

STAR Situation, Task, Action, Result

The parent, and the spoken one. STAR separates the setting from your remit; PAR merges them into the damage. Use STAR in the room, PAR on the page.

SOAR Situation, Obstacle, Action, Result

The interview specialist. SOAR is about resistance you overcame — often a person; PAR is about something broken you repaired — usually a system or a process.

5W1H Who, What, When, Where, Why, How

What to use if the document is a formal post-mortem rather than a personal account. 5W1H establishes the facts without a protagonist.

BAB Before, After, Bridge

The same repair arc told about a customer for marketing purposes, with the effort deliberately left out — which is exactly the part PAR exists to show.

Five Ways People Get PAR Wrong

1
Leading with the fix

The defining PAR failure. The fix is the least distinctive true thing in the story; the diagnosis is what separates you from anyone else who could have typed the same command. Ask for how you found it, explicitly.

2
A problem with no duration or victim

"There was an issue" is an incident. Four consecutive months, 3,000 invoices, finance chasing by hand — that is a problem, and the scale is what makes the repair worth reading about.

3
Not saying what you ruled out

Without it a correct diagnosis is indistinguishable from a lucky guess. One clause fixes this and almost nobody writes it.

4
Blaming the previous owner

Tempting, since the ownership vacuum is genuinely part of the problem. Describe the vacuum, never the person — a panel reads blame as a signal about you, not about them.

5
Claiming permanence

"Now permanently resolved" invites the one question you cannot answer. "Five clean runs since" is stronger precisely because it is bounded by evidence.

6
Inventing the impact

Revenue saved, hours recovered, percentages. A model will supply all three on request, and this is a document read by people who were there.

PAR Questions

What does PAR stand for?

Problem, Action, Result. It is a compressed structure for describing something that was broken and how you repaired it.

What is the difference between PAR and CAR?

The second slot, and the usual length. CAR's Challenge admits a goal, a stretch or an opportunity; PAR's Problem insists something was wrong. CAR is normally a single-sentence bullet, PAR a paragraph. If your story is a repair and you have room to explain it, use PAR.

What is the difference between PAR and STAR?

STAR separates the situation from your task and is built for spoken interview answers. PAR merges them into the damage and is built for written accounts — reviews, promotion cases, write-ups.

What should go in the Action section?

The diagnosis before the fix, including what you ruled out, then the fix itself, then ideally the thing that stops it recurring — a check, a runbook, an owner. The Action paragraph should be the longest of the three.

Why does the diagnosis matter more than the fix?

Because the fix is usually the least distinctive part. Many people could have added the index; far fewer would have read four months of logs first. Seniority shows in how the cause was found, not in the command that resolved it.

Can I use PAR for a problem I caused?

It reads badly and the framing tends to expose it. PAR is built around inheriting damage. If the story is about recovering from your own mistake, SOAR handles it more honestly — and "tell me about a time you failed" is a SOAR question.

Generate a PAR Prompt Instantly

Skip the manual template — Frompting applies PAR to your topic in one click.

Try it Free

Framework Details

Name PAR
Stands for Problem-Action-Result
Domain People & Teams
Steps 3
Access Pro
Steps at a glance
P Problem
A Action
R Result