How does Henry work with Process Street?

Henry designs the operation and specifies each step. Those specifications become Process Street workflow templates: Work Plane intent becomes the task title and description, roles become task assignments, quality bars become approval tasks and stop tasks, and the Fit Assessment tells you which tasks should be automated versus human-executed. You stop shipping checklists that document chaos.

Process Street has conditional logic and approvals already. Why add Henry?

Process Street provides the execution primitives — tasks, forms, conditional logic, approvals, automation triggers. Henry provides the design decisions that say which conditionals you need, where approvals actually belong, and which tasks have no business existing at all. The features are in Process Street. The judgment about how to use them is in Henry.

Can Henry help me redesign a messy Process Street workflow?

Yes. The common failure mode is a workflow that grew organically: someone kept adding tasks as problems arose. Henry runs a diagnosis on the operation underneath, rebuilds the step specification, and hands you a clean template structure. You import the designed workflow into Process Street and retire the accumulated clutter.

Designing workflows for Process Street

Design the checklist before
you run it.

Process Street is excellent at running repeatable workflows. Henry decides what those workflows should be — the steps, the order, the conditions, the approvals, and the automation boundary — before you ship the first template.

The checklist design gap

Why do checklists
stop describing the work?

You build a clean onboarding template. Six months later it's 47 tasks long, three of them contradict each other, two departments have added branches for their edge cases, and the team skips half of it because "that part doesn't apply to us anymore." The checklist stopped describing the operation somewhere around month three.

That drift is a design problem. Each new task got added as a response to a specific incident, not as part of a designed operation. Nobody asked the design questions up front: which steps actually belong in this operation? What's the real sequence? Where do human approvals earn their keep? Which tasks should have been automated from the start?

Henry runs those questions as its core job. He maps your operation using the AAAERRR methodology from Deliberate Work, specifies each step across three planes, and hands Process Street a designed workflow to run. The template you publish represents a system you've designed — not an archaeological record of the last year of incidents.

For operations-focused teams and consultants setting up client systems, this is the difference between shipping a checklist and shipping an operation.

Tasks from step intent

Every Process Street task gets its title, description, and purpose from a Henry Work Plane intent. No more tasks titled "Check the thing."

Conditionals from Fit Assessments

Steps that branch on human judgment versus automation become conditional logic and stop tasks, placed at the decisions that actually matter.

Assignments from roles

Execution Plane role assignments become Process Street role-based task assignments. Runs auto-route to the correct owner, not a default.

How it maps

How do Henry steps
become Process Street templates?

Henry Specification	Process Street Element
Work Plane — Intent	Task title and description
Work Plane — Inputs	Form fields and variable captures
Work Plane — Outputs	Completion artifacts and passed variables
Execution Plane — Role	Role-based task assignment
Execution Plane — Trigger	Workflow run trigger (schedule, Zapier webhook, form)
Execution Plane — Mode (human)	Approval task or stop task
Experience Plane — Quality bar	Required fields, approval criteria, conditional stop
Fit Assessment	Automation trigger vs. human task — and whether the task belongs at all

These are design-to-execution patterns, not a product integration. Henry produces specifications you translate into Process Street templates.

The specification depth

What makes a step
workflow-ready?

A step specified across all three planes already contains the task description, the form fields, the role, the quality gate, and the automation decision. Every task in your Process Street template earns its place because the design upstream says it should exist.

Work Plane

Intent, inputs, outputs. What this step accomplishes, what it consumes, and what it produces. The strategic "what" and "why" of every atomic unit of work.

Execution Plane

Who performs this step, how it gets done, when it fires, and in what mode — human, AI, or hybrid. The specification that makes delegation possible.

Experience Plane

What the stakeholder should feel. The emotional and perceptual design of each interaction — the layer most operations never specify but always need.

Design the operation.
Then run it in Process Street.

Start with a diagnosis. End with workflow templates where every task earns its spot on the list.

Talk to Henry →

Not sure if Henry is right for you? Book 15 minutes with Joe →

Design the checklist beforeyou run it.

Why do checklistsstop describing the work?