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. Any two, go find the decision.

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 path is a constraint. 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 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 saysSounds likeAsk instead
“We have a spreadsheet for that.”Tool problemIs it working, or compensating?
“Then I send it over 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 where undecided things live, because the normal path was designed and the exception never was.

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.

Work them in order. Manual isn’t broken. Compensating for something that was never designed is.

EWhere AI helps, and where it can’t

Feed it

  • Meeting and interview notes
  • A messy process description
  • How the work actually ran last time
  • Real examples, the ugly ones included
  • The rule you just wrote

Ask it to

  • Reconstruct the workflow, step by step
  • Flag every step with no owner
  • Mark where the work waits, and why
  • Find the cases your rule doesn’t cover
  • Turn the outcome into system requirements

Still yours

  • Deciding what is actually wrong
  • Settling the disagreement
  • Getting alignment with stakeholders
  • Choosing the tool
  • Sequencing what to fix first

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.

Send me what you wrote down.

Copy your answers and email them over: jen@blueprint-solutions.io

blueprint-solutions.io

Know someone I should meet? Start here