Blueprint Solutions

What’s Actually Broken?

A way to work out whether an operations problem is a decision, a process, or a tool, before you spend money fixing the wrong one.

Two ways to use it. Fill it in on something that’s bugging you right now, or skip the boxes and take the reference into your next meeting. Whatever you type stays in this browser, on this device.

Why this is worth ten minutes

One complaint. Four different causes.

Someone says “our CRM is broken,” so the obvious move is to buy a new CRM. Here is what can actually sit underneath that one sentence, and what the migration touches.

No agreement on what belongs in it

Still broken

Nobody owns keeping it current

Still broken

Information arrives too late to use

Still broken

The CRM genuinely can’t do it

Fixed

Same symptom, four very different fixes. Three of the four, you paid to move the problem. That’s why the tests below run in the order they do, and why the tool question comes last.

00

Pick one real annoyance.

Not your biggest strategic problem. Something concrete, that happened, more than once.

The symptom what you’d say out loud
Your current diagnosis the fix you’ve already half-decided on

Keep that second box honest. You’ll test it against your answer at the bottom.

01

What is actually happening?

Pick the last real one and walk through it. The questions are in past tense on purpose, because you’re reconstructing one thing that happened rather than describing how it’s meant to go.

Don’t ask:“Why isn’t this working?” Ask:“Walk me through the last real one.”

The factsSet the scene, and stop there. No interpretation yet, and no why either.

What started the work?
Who got involved, and when?
What information did they need?

The frictionWhere the work stopped, slowed, or repeated. These are the answers to pull on. Keep asking why until the answer stops changing.

For example

  1. It sat for two weeks.
  2. why?Finance didn’t know it was ready.
  3. why?Nobody ever decided whose job it was to tell them.
  4. why?Same answer. That’s the bottom of the thread.

Write down what you found there. Resist naming it.

Where did someone wait, improvise, or chase?
What got redone, and what came of it?
Anything else that made the work stop, slow, or repeat?

Every one of those answers is evidence. None of them is a diagnosis yet, and the three tests below are where you find out which.

02

Run the three tests.

Read each one against what you wrote above, not against your general sense of how things go. If your answers don’t support a box, leave it unchecked.

Decision test

Is the rule missing? Check what’s true. Multiple signals are a reason to investigate the decision layer.

Anything checked above stays as your notes. It doesn’t count as a signal until you’ve asked.

Process test

Is the path missing? Two yeses, and the process is part of the problem. That doesn’t rule the tool out, so still run the third test.

If both are yes, where does it break?

Anything checked above stays as your notes. It doesn’t count as a signal until you’ve asked.

Tool test

This one comes last because it has no answer until the other two are settled: can our tools reasonably support the rules and process you’ve decided you need?

Every one of these is a recurring cost, not a one-time annoyance. That’s what separates irritating from a constraint.

Anything checked above stays as your notes. It doesn’t count as a signal until you’ve asked.

What your answers point to

03

Expect an overlap.

Most real problems live in an overlap. Two at once is the normal case, not the messy exception.

Naming them isn’t the point. Knowing which to fix first is. When they’re tangled, one is holding the others in place.

04

Name the one to fix first.

Not all three. The one the others are waiting on.

The only question that changes what you do next

Which one is holding the others in place?

Fix that, and the other two stop being blocked. Fix either of the others first, and you spend a quarter finding out.

First move

Back at the start, you said the fix was

Keep this half

The Reference

Nothing to fill in here. This is the method itself, for whenever you need it again.

AWhat people say is a clue

What someone saysPossible, but not certainAsk instead
“We have a spreadsheet for that.”Tool problemIs it working, or compensating?
“Then I send it to Finance.”Process problemIs that handoff clear and reliable?
“The system won’t let us.”Tool problemWhat are we asking it to do, and why?
“It depends who you ask.”Process problemIs there actually an agreed rule?

Nobody says “we have a decision problem.” The obvious reading on every row is a reasonable reading. It just isn’t the only one.

BIf you’re not sure, ask these

  • What counts as done?
  • Which definition are we using?
  • Who gets priority?
  • Which date controls this?
  • What requires approval?
  • Who has authority to decide?
What happens when the normal rule doesn’t apply? Highest yield in the list. Exceptions are especially useful because they often reveal where the rule stops being clear.

Two of these is usually enough. If people answer differently, that’s your finding.

CAsk three or four people, separately

“If this worked perfectly, what would happen?”

In a group you get one blended answer, usually the most senior person’s. Ask for a sequence of events, not a picture.

Then ask: did everyone describe the same thing?

  • Nobody can say what the answer should be.Decision problem. Nobody decided.
  • Someone can, but it never reached the work.It was decided and never landed. Look at the process.
  • People genuinely need different answers.Ask what breaks when they differ. If nothing does, leave it alone.

DThe five places a process breaks

01HandoffsWork changes hands, and something waits or gets lost in between.
02OwnershipEveryone owns a piece. It only moves when someone chases it.
03Inputs and timingThe information doesn’t arrive at the right time, or it never arrives.
04ApprovalsWork stops waiting for a yes, and it isn’t clear whose yes it is.
05ExceptionsThe normal path was designed. How the odd ones move never was.

The first three are usually straightforward process issues. Approvals and exceptions are more nuanced: if everyone knows what should happen but there’s no reliable path, that’s process. If no one knows what should happen, go back to the decision layer.

Manual isn’t broken. The problem is when people are manually filling gaps the process should handle.

EWhere AI helps, and where it can’t

Before you know what kind of constraint you have: Give AI the raw material, not your diagnosis. Ask it to organize what happened, flag inconsistencies, and separate observation from assumption.

Decision problems

Feed it

  • Evidence you gathered across stakeholders
  • A proposed rule, if one exists
  • Real examples, including the messy ones

Ask it to

  • Surface conflicting assumptions and terms used differently
  • Flag unresolved definitions or places where a rule is missing
  • Pressure-test a proposed rule against edge cases
  • Show what breaks if the rule is wrong

AI can surface the gaps. You still decide what matters and settle them.

Process problems

Feed it

  • How the work actually ran last time
  • Who touched it, and when
  • Where it waited or got redone

Ask it to

  • Lay it out step by step, with an owner for each
  • Flag every step with no owner
  • Mark where the work waits, and why
  • Show where the process is compensating for another problem

AI can map the path. You still have to fix the break.

Tool problems

Feed it

  • The outcome you need
  • The process it has to support
  • Inputs, outputs, roles, edge cases, and constraints

Ask it to

  • Turn this into system requirements
  • Separate must-haves from nice-to-haves
  • Flag risks, gaps, and tradeoffs
  • Draft evaluation criteria for comparing options

AI can clarify the requirement. You still choose the tool.

Anonymize or generalize sensitive information first. AI needs the structure, not the names. It organizes the evidence. You decide what’s wrong.

The takeaway

Look underneath it.

  1. Start with what happened, not what’s wrong. Ask someone to walk you through the last real one.
  2. Answers are evidence, not diagnoses. Collect them before you decide what’s broken.
  3. Expect an overlap. Two at once is the normal case, not the messy exception.
  4. Fix the one holding the others in place. Not all three. The one the others are waiting on.

Keep in touch

Want to stay in the loop?

A few times a year, when a project wraps up and I have room for another, I send one short email to let you know. I also occasionally share practical resources that might be useful.

Totally optional. Unsubscribe anytime.

Jen Pakravan

Jen Pakravan

Blueprint Solutions · Operations Consultant

Operational strategy and systems design for founder-led B2B companies, 15 to 150 people, whose informal systems have stopped scaling.

Want a second read on it?

Copy your answers and email them over. I’ll tell you what I’d look at next: jen@blueprint-solutions.io

blueprint-solutions.io

Know someone I should meet? Start here