How the work actually happens

01The deliverable is the document

This is the sharpest decision we have made, and it is worth stating flatly because it changes what gets built first and what we refuse to build yet.

It should read like a story rather than a diagram legend. Pages of it. What the steps are and in what order. Who does each one, by name and by role. Which tool each step happens in, including the spreadsheet nobody would call a tool. How long things take and where they sit waiting. What breaks, and what that break is connected to. The different ways different people complete the same workflow.

Everything else we want to build is a byproduct of getting that one artifact right. We learn what people actually do, what the tools actually do, what works and what doesn't — and above all, how the work currently really happens, which does not exist in written form anywhere in the customer's business today.

How it gets accurate: many sources, aggregated

The document is not written from one input. It is aggregated from as many as we can get, and each one is incomplete in a way the others fix.

• The library alone is a template. It knows the usual shape of a procurement intake or a QBR, which is why the workspace is useful in the first minute — and worthless by the second day if nothing localises it.
• Their documents are the official story. Almost certainly stale, which is the useful part: the distance between it and reality is the drift.
• Tool exhaust has no intent. The logs show a step took nine days. They cannot say the approver was on leave and everyone routes around her.
• People are the primary source, and they are the hard one. Interviews and screen recordings are how we get detail nothing else can produce — and asking many people rather than one expert is the entire difference between this and a recorded walkthrough.

Standardisation comes out of the deviations

Because we go to the whole team rather than one expert, we see every version of the workflow, not the tidy one. That turns into a specific and unusually useful loop:

• Find who deviates. Four people run the same workflow three different ways. Only a product that asked all four can know that.
• Learn from the deviation rather than flagging it. Some shortcuts are better than the documented path, and the person taking them is usually right.
• Fold the good ones into the core workflow, then push adoption of the version that now reflects the best of what people actually do.

That is a route to standardisation that starts from reality instead of from a policy document, and it is unavailable to anything that records a single subject-matter expert.

What this buys next: real job descriptions

And only after that is it honest to talk about what can be automated, what can be handed off, who should be doing what, and where someone needs training. Every one of those questions is downstream of a true document, which is why we are not answering any of them yet.

What we are deliberately not building first

Not recommendations. Not automation scoring. Not hours-freed projections. Spreading the next few months across the document and the advice produces two average things, and the advice is worthless anyway when it sits on a workflow nobody has verified.

One thing, better than anyone else can do it: take a business that cannot describe how it works, and hand it an accurate written account of how it works.

The document is a view of the map, not a report

A standalone report becomes a second source of truth the moment it is written, and starts rotting immediately. The workflow document avoids that by never being a separate thing — it is rendered from the map, so what the loop produces is diffs to the map, and the document changes because the map did. That is what lets it be the deliverable and still be true a quarter later.

02The first 48 hours

The bar: one workflow documented end to end, with evidence, inside 48 hours — starting from nothing but their domain name.

Three base artifacts have to exist before a workflow can. Who is in the business. What roles those people hold. What tools exist and what those tools do together. Between them they say what the company is capable of, and workflows fall out of the far end.

Three workflows, not thirty

The cap is deliberate and does two jobs. It teaches the loop on a small enough surface that the customer can see the whole shape of it. And it hands them something to win with immediately — one workflow they can take into a meeting and make noise about, rather than a map of the business they have no idea what to do with.

After that, discovered workflows accumulate in a registry and the customer picks the next one when they care about it. Coverage comes from repetition, not from a big-bang engagement.

Two kinds of customer, and both have to work

The blind case is the more common one at the size we are aiming at, it punishes a product built around a customer who already knows the answer, and it is the case our competitors are worst at.

Interview-first or guess-first — same machine

• Interviews are a data point, not a phase. They arrive, they get folded in, the artifacts regenerate. Whether they arrive before or after the first document only changes what confidence it opens at.
• Interview-first opens higher. The evidence preceded the document.
• Guess-first opens lower and climbs. The customer chooses which workflow earns the effort of raising it.

What 48 hours forces

• Research is time-boxed. A good-enough profile in ten minutes beats a better one tomorrow, because tomorrow is half the budget.
• Interviews are minutes, not half an hour. Nobody completes a long one inside a day.
• The cohort is small and chosen. Five people who actually run the workflow, not thirty who might.
• One workflow deep, not the whole map.
• Partial analysis stops being a fallback. At 24 hours we will have some of the answers and never all of them, so the design has to be honest at any coverage rather than waiting for completeness it will not get.

03What the research actually reads

Hour zero to one is the leg everything else stands on, and the most common way to get it wrong is to treat it as building a dossier. It isn't. It answers three questions and nothing else, and every angle is judged on whether it moves one of them.

What kind of company

Motion, size, stage, sector. This selects which slice of the library applies — a sales-led enterprise business and a self-serve one do not run the same workflows.

What they want this year

The three goals we put up for correction. Sourced from what leadership has already said in public wherever possible, rather than inferred.

What they measure

The metrics the business actually watches. This is the join — it lets us say a specific workflow moves a specific number, which is the difference between an interesting map and a funded one.

The angles worth mining

The pricing page is the highest-signal page on the internet. No prices means sales-led, which means there is a qualification workflow, a security review, a procurement dance and a renewal motion. A credit-card signup means support and onboarding volume and no AEs. Seat-based against usage-based changes what "expansion" even means. You learn more about how a company operates from its pricing page than from its About page.

The careers page is the org chart in disguise. Which functions exist, which are growing, who reports to whom — and job ads name the tools. A "first RevOps hire" posting says they don't have one and it is hurting. Twelve open AE roles says land-grab, and every workflow we suggest should be revenue-side.

Customer logos tell you which workflows are mandatory. Enterprise logos mean security questionnaires, legal review, procurement and MSAs — those workflows exist whether or not anybody owns them. SMB logos mean high-volume support and self-serve onboarding instead.

Leadership's public voice is where goals actually come from. Posts, podcasts, conference talks, investor updates, the annual report if they are listed. A founder saying "this year is about net revenue retention" hands us goal one, sourced and quotable, which is far stronger than anything we could infer.

Reviews are a bug tracker for their operations. G2, Capterra, Reddit. "Onboarding took three months." "Support never gets back to you." Customers naming workflow failures out loud, from outside the building, before we have spoken to anyone inside it.

Trust centres and security pages are the sleeper. A SOC 2 page means they run vendor review, access review and incident response — because they had to. Handbooks, engineering blogs and status pages do the same job where they exist.

The tool stack implies the processes. Greenhouse means a hiring workflow. Zendesk means a support workflow. A general ledger means a month-end close. We can walk backwards from stack to process without asking anyone a question.

Regulation forces workflows into existence. Health, financial services, government — processes that must exist regardless of what anyone would think to tell us.

Structural priors do most of the lifting. A 250-person sales-led B2B company runs a knowable set of workflows. The research is not deriving that from scratch; it is choosing which priors apply and finding where this company deviates.

How the research runs, in plain terms

The rules it runs under

• Public only. Nothing behind a login, nothing requiring an account, nothing a site has asked not to be read.
• Time-boxed by design. A handful of well-chosen pages beats an exhaustive crawl, because the hour-one deadline is the point.
• Company-level before people-level. Before anyone is a customer we stay at the shape of the organisation, and named individuals stay limited to the leadership a company already publishes about itself. Handing a stranger a list of their staff is a worse first impression than an honest gap — and in the EU it carries a GDPR Art. 14 notification duty.
• Never scrape professional networks. hiQ v. LinkedIn settled with a permanent injunction on the contract claim — the CFAA defence held, the user-agreement one didn't. Proxycurl, which sold exactly this, shut down under legal pressure. Licensed providers or nothing.
• Gaps are stated, not hidden. "We could not find how you handle renewals" is a legitimate output, and usually the most interesting line on the page.

Framing decisions

Where it falls over

• Too quiet to research. Small, stealthy or offline-heavy businesses have almost no public surface. Priors carry more weight and confidence has to open lower — stated, not hidden.
• Which entity is this, actually? Holding companies, multiple brands, a domain that is one product of five. Resolving it may be the first question we ask rather than infer.
• The site is marketing fiction. Fine. We are inferring shape, not truth, and the gap between the public story and the internal one is the product.
• Recent change invalidates everything. A reorg, an acquisition or a new CEO six weeks ago outweighs a decade of older material. Recency has to beat volume.

What good looks like at hour one

A page short enough to read in ninety seconds. Specific enough that they want to argue with it. Honest about which parts are guesses. Ending in three goals they can nod at or fix, and three workflows that feel obviously theirs rather than obviously generic.

04The three base artifacts

Workflows cannot exist before these three do. Get them fast and rough and everything after has something to stand on. Skip them and every workflow is a template with the customer's logo on it.

One — who is in the business

People, from public professional data and whatever directory they connect. This is the weakest of the three at hour zero and the strongest once a directory is attached, which shapes the whole sequencing below.

Two — what roles exist

Each person matched against the role library — roughly a hundred roles, fewer once seniority is stripped out. Matching alone is not enough. Real companies run roles no standard taxonomy contains: a research lead at a brand-tracking company, a partnerships manager who polices a territory.

So the library has to mint roles it has never seen and keep them, not force the nearest fit. This is not theoretical: pulling positions from public profiles and running them against the current coverage map surfaced roles that exist in neither our mapping nor Human Layer Lab's. How minting works without fragmenting the library is open question 06.

Three — what tools exist, and what they do together

Held already for existing customers: stack, spend, seats, logins. Unknown for net-new, and said so rather than guessed.

It cannot stop at SaaS. The spreadsheet that runs the handoff, the internal app someone built last quarter — those are load-bearing, and a map that only sees purchased software will misread the business. At one large insurer, everyone building their own little app is actively preventing standardisation; a purchased-software-only view would show a tidy stack and miss the actual problem.

Lead with tools, not people

From a domain alone the ordering above is not the ordering we show. The people artifact is the weakest thing we can produce cold; the tools artifact is the strongest, and it is free, instant and verifiable in ten seconds.

Until then, what we show stays aggregate:

Aggregate is more impressive and less creepy. Worth being honest internally about what a cold roster is worth anyway: realistic yield is 40–70% of a 200-person company, skewed to sales, marketing and leadership, with titles 6–18 months stale. Engineering and ops are systematically under-covered.

Coverage is a first-class number

Estimated headcount against people found drives the confidence ceiling directly, and it should be visible: "people 26% — connect your directory to lift this." That is the ceiling mechanic made concrete rather than abstract, and it is the same argument as the CRM one in the commercial doc.

Then, and only then, workflows

People plus roles plus tools give capabilities. Capabilities plus goals plus metrics give the workflow shortlist. Honest about the ceiling: assuming standard shapes gets us maybe halfway. We do not get clean on a workflow until documents are ingested, people are interviewed and the tools are read.

05Why we propose the goals but not the steps

The two asks in onboarding are pitched at deliberately different levels, because the customer knows one and not the other.

Company level

They know. Sales-led or not, how the org is arranged, what this year is about. So we show our reading and invite them to knock it down.

Workflow level

They don't. A leader knows the workflow exists and roughly what it's for; they rarely know who does which step, in what order, with which tool. So we ask, accept "I don't know", and go find out.

Asking the wrong question at the wrong level is how onboarding turns into homework. It is also why the agent writes the interview, not the customer: anyone who could author good questions about a workflow already understands it well enough not to need us.

The risk on the other side is real and unresolved — correcting only beats authoring if the proposal is close. See open question 03.

06Confidence is the second axis

Most of the map is not observed directly. Some is inferred from spend and tool usage, some read out of documents, some confirmed by a person. Those are very different grades of evidence, and presenting them as uniformly authoritative is how a product in this category loses an account.

So every claim records its source, a confidence, and a last-checked date. Confidence decays: a workflow nobody has confirmed in eight months is a hypothesis again, and "last checked" is what schedules the next round of discovery without anyone planning it.

The ceiling

A document can only get so far on inference and interviews. Past a point the score stops moving, and the reason is stated on the page: we cannot see how deals actually progress until the CRM is connected, so this stays at eighty.

That is not a paywall dressed up as a progress bar. It is true, it is checkable, and it converts the integration ask from something we push into something they pull — which is the whole commercial mechanic, covered in the commercial doc. Whether it reads as honest is open question 05.

Re-verification is one click

Every document carries when it was last verified. A customer who thinks three months is too long for their business does not file a request — they press re-verify, and it goes back out to everyone on that workflow: here's the document, do you still work this way? A thumbs up is a fresh verification. Anything else is a diff, with the person and the change attached.

It fires on its own too, which is the part that matters:

• Decay. Nothing confirmed in months drops back to a hypothesis and schedules itself.
• Observation. A connected tool shows someone doing the step somewhere else, or in a different order. Also: someone dropping out of a directory sync is a departure, which should invalidate a step's owner and trigger re-verify.
• Signals from elsewhere in the product. Someone submits an intake request looking for a new way to solve exactly this problem — which is a statement about the workflow whether or not they meant it as one.

07The capability map

Capabilities down the side, business units across the top. Each cell answers both questions at once. Blank is a real answer: "not applicable" means this business unit genuinely doesn't do this, and differs from "not yet mapped", which means nobody has looked. Without that distinction, absence is ambiguous and coverage can't be reported honestly.

Close new business at 48% and inferred is the cell that generates the next interview. Retain revenue, not yet mapped, generates the one after. The map produces its own work queue — which is why coverage is a product surface rather than an internal metric.

08The loop

What is still guessed after all four sources is itself the finding, and it writes the next round of questions. Whether the loop actually closes without a person choosing to close it is open question 04 — and it is the word "continuously" in our positioning doing all the work.

09The model

Two hierarchies that are easy to confuse and must not be merged. One describes the work: a function contains capabilities the business must be able to perform, each realised by workflows, each made of ordered steps. The other describes the organisation: business units group departments, which hold people.

They meet at exactly one place. The capability is the only object that carries ownership — one accountable department, from which the owning business unit is inferred rather than stored. Keeping both would let them drift, with nothing to say which is right.

Ownership rules

• A capability has one owner department, and may have contributors. The business unit is inferred from the department, never stored alongside it.
• A workflow has one parent capability.
• A workflow may be run by a department in a different business unit from the one that owns the capability.

Everything scopes to the workspace, which is the hard data boundary — EMEA, Enterprise, an acquired subsidiary. Nothing scopes below it, because a narrower scope would make the map invisible to contributors in other business units, and the cross-BU seam is precisely what we are trying to see.

10Why money attaches to the job

Vendors and spend attach to the task — the specific job being done — never to the workflow it sits inside. This is the distinction that makes "where is the money actually going" answerable.

This is the quantified payoff worth leading with commercially: not hours freed, but duplicate spend found — a number a CFO can repeat without us in the room.

11The map is an API

The most demanding reader of the map is not a person. It is every other agent the customer is already running — the one drafting their vendor emails, the one triaging their tickets, the one they built themselves last month. All of them are working without any idea how the company actually operates, which is why their output reads generic.

Confidence is load-bearing here in a way it isn't on a screen. A person who reads "probably owned by Finance" discounts it automatically. An agent acting on the same string does not — unless the grade travels with the claim. So no surface ever returns a bare fact: source, confidence and last-checked ride along on every response, and a caller can demand a floor and get told what it didn't get rather than a confident guess.

Authorization is the same one the product uses. The tenancy boundary and the relations that gate a workspace in the UI gate these surfaces too. An outside agent reads exactly what the person or service it acts for could read — never a flattened copy of the map with the permissions filed off.

Everyone ships MCP now — what's behind it is the difference

An endpoint is table stakes; our nearest competitors already have one. What comes back through it is not comparable. Serving a generic role taxonomy makes an agent sound plausible about a job title. Serving this company's workflow as it actually runs — the real steps, the people really on them, the tools really underneath, each with a confidence grade — is what makes an agent correct.

A document is read once and filed. A context endpoint is called on every task, by every agent, forever — and the calls tell us which parts of the map are load-bearing. That is feedback on where the next round of discovery should go, arriving without anyone being asked, and it is why the unlimited pricing shape and this surface are the same decision.

12Where we are

The foundations are built and running in production. The reference library — the working draft every new customer is born with — is loaded and validated:

The library is versioned: we fork a version, edit it, promote it, and workspaces created after that are born from it. Once seeded, the map belongs to the customer — later promotions never rewrite what they've corrected. How much of it a customer is born with is open question 08.

The same applies to the outside surfaces. The service already speaks HTTP with the tenancy and authorization in place, which is the hard half — but the MCP server and the CLI do not exist yet. They are small once the model is right, and the model is right; they are not shipped, and this document should not imply otherwise.

What the MVP has to prove, and what is deliberately outside it, is in the open-questions doc.