/suede-ops-assessment

name: suede-ops-assessment
description: "Suede AI operations-assessment discipline that maps how work actually happens before anyone designs a system: floor-level interviews with the people who do the work, an inventory of every silo including spreadsheets and inboxes used as databases, friction quantified in the requester's own numbers, opportunities ranked by annual value against build complexity, and adoption watched for the thirty days after launch. Use when nobody can answer what to automate, when an operation needs auditing before a build, when tribal-knowledge and key-person risk has to surface, or when a shipped system is quietly being routed around. NOT FOR: deciding what to build and in what order once the map exists (use suede-ops-architecture); researching external customers rather than internal operators (use suede-customer-research); lead lifecycle, scoring, and CRM routing rules (use suede-revops); product instrumentation and dashboards (use suede-analytics); getting a new user to first value (use suede-onboarding)."
metadata:
  version: 1.0.0

Suede Ops Assessment

Iron law: map the floor, not the org chart.

Every operation has two maps. The leadership map describes how the business is meant to run. The floor map describes how the work actually gets done, including each workaround, each unofficial spreadsheet, and each extra step that exists because something broke once. A system designed from the leadership map gets routed around, because the people doing the work can feel the mismatch on day one.

This skill produces the floor map and the numbers attached to it. It stops before deciding what to build.

The requester's numbers are given

Their hours, costs, volumes, error rates, and history are inputs, not claims to audit. No step here verifies, scores, hedges, or gates on a figure the requester supplied.

What does get audited is anything **this skill** produces: a benchmark it reached for, an estimate it filled in, a process step it inferred rather than heard. Mark every one of those inline as `[assumed]` and list them in the Output Contract, so a reader can tell the operation's own numbers from this skill's.

Never substitute an industry average for a number the requester has. Ask for theirs, or record the line as missing.

Before Starting

1. **Scope**: which processes, departments, or surfaces are in the assessment. 2. **Access**: what the requester has authorized you to read. Work inside it. 3. **Who does the work**: names or roles per process, separated into people who perform it and people who manage it. 4. **Self-applied or on behalf**: a founder assessing their own operation reads Step 5 differently from an outside team assessing a client's.

Read `references/interview-guide.md` before the first interview.

Step 1: Interview the floor

Interview at least one person **per process** who performs it, not only the person who manages it. Where the two descriptions differ, record both and mark the performer's version as the floor map.

Run it as a walkthrough rather than a survey: the question is what happens next, repeated until the process ends. The guide carries the full question bank; these four earn their place in every interview.

• Walk me through this from the beginning, including the steps too small to

mention.

• What do you type or copy by hand more than once?
• Where does work sit and wait, and who is it waiting on?
• If volume doubled next quarter, what breaks first?

That last one returns more than the rest combined. People work next to the weakest part of the operation every day and are rarely asked about it.

**Count the exceptions rather than describing them.** When someone says a path runs "only sometimes", ask how many of the last twenty cases took it. An exception that turns out to be a fifth of the volume is a main path nobody has drawn yet.

**Follow up after two days.** People remember the forgotten step, the second spreadsheet, and the quarterly exception once the interview has settled.

**Gate.** Every in-scope process has at least one performer interview. When the requester performs the process themselves, their own walkthrough is the performer interview: record it as such and move on rather than halting for a second person who does not exist.

**Halt format.** Stop. Name each process covered only by management description. Offer: schedule the performer interview, proceed and mark that process `[leadership map only]` throughout the blueprint, or drop it from scope. Wait for the choice.

Step 2: Inventory every silo

A silo is any place operational information lives that other systems cannot see. Catalog all of them: software, spreadsheets, shared drives, inboxes used as databases, and the messaging channels where decisions actually get made.

Record per entry: what it holds, who writes to it, who reads from it, what it overlaps with, and its monthly cost.

Cite a proof path for anything claimed to be live: a last-write timestamp, a seat count, an invoice line, or a recent export. A tool nobody can produce evidence for is recorded **unknown**, never assumed dead or alive.

**Steps with no system behind them are the finding, not a gap in the inventory.** A process step that lives only in somebody's memory is tribal knowledge: record it, name the person the operation stalls without, and carry it into the ranking as key-person risk.

**Gate.** Every step from Step 1 resolves to one of three: an inventory entry, a named tribal-knowledge holder, or manual work that depends on no system at all. Physical and judgment work belongs in the third bucket; recording it as tribal knowledge invents a risk that is not there.

Step 3: Quantify the friction in their numbers

Attach a figure to each bottleneck, built from three components. Show the inputs beside each result so a reader can check the arithmetic.

| Component | Formula | |---|---| | Labor | hours per week × loaded hourly cost × 52 | | Error | cost per