# Process Desk > The process in someone's head, measured and written down: paste a business process as one step per line - the step, who does it, how long it takes, how long the work waits before it, the share passed on complete and accurate, its kind - and the browser measures it for free from the value-stream-mapping definitions; then one metered lane finds the waste and proposes a future state the browser applies and prices, and the other writes the standard operating procedure with a RACI the browser lints. Live at https://process-desk.skillsafe.ai/ · API tutorial at https://process-desk.skillsafe.ai/api.html · Tokens at https://process-desk.skillsafe.ai/tokens.html ## What it does One work object: one business process - a name, a description in the user's words (triggers, exceptions, what goes wrong, what they want), and a step table. Rows are pipe-, tab- or semicolon-separated with an optional header (`step | owner | process time | wait before | %C&A | kind | people`) or numbered prose (`3. Finance checks the budget line @Finance (20 min, wait 1 day, 95%)`). Durations accept minutes, hours, working days and weeks; the user sets hours per working day (default 8) and days per week (default 5). Kinds are manual, automated, approval and decision, inferred from the step name when absent. An optional weekly demand and a per-step people count enable load and Little's-law figures. The free engine (no account, no model), from Martin & Osterling, Value Stream Mapping (2014): a step's lead time is the wait before it plus its process time; total process time and total lead time are sums along the timeline, a parallel group counting once at its longest member; activity ratio = total PT / total LT; rolled %C&A = the product of every step's %C&A. From Little's law (Little 1961; Hopp & Spearman): items in process = demand x lead time, and each step's load = demand x PT / (people x hours per week). Also: handoffs (owner changes between consecutive steps), ping-pong (work returning to a role after one step elsewhere), roles and their touch-time share, approvals / decisions / manual / automated counts, the longest wait, the bottleneck (highest load when a demand is given, else the longest process time), a swimlane diagram, a Mermaid flowchart export, CSV and Markdown exports, and a list of waste candidates in the skill's five categories (waiting, rework, handoffs, over-processing, manual work) for the model to judge. Posture bands are this desk's own: stalled under a 5% activity ratio or a 50% rolled %C&A; sticky under 25% or 80%, or with more handoffs than half the steps, or a step loaded past capacity; otherwise flowing. Two metered lanes (gpt-terra, one system prompt with a task router): - `improve` (from @anthropics/process-optimization) - the model reads the current state (quoting the engine's figures), names the waste by category with the steps and the evidence, proposes the future state as OPERATIONS - remove, merge, parallel, automate (new PT), cut_wait (new wait), set_ca (new yield), reassign, add (a checkpoint) - which the browser applies to the table and prices: lead time, touch time, activity ratio, rolled %C&A, handoffs, steps, approvals, manual steps, labour hours per week and items in process, before and after. The model describes the future state and the impact (time saved per cycle, error rate, cost, employee satisfaction) in words only; the figures are the engine's. An implementation plan in two to four phases. Verdict = the engine's posture (flowing | sticky | stalled), which the model must copy. - `document` (from @anthropics/process-doc) - the model writes the SOP in the skill's own template: purpose, scope (included / excluded), a RACI matrix (one row per step; linted in the browser for exactly one Accountable and at least one Responsible per step, with an advisory when Responsible differs from the table's owner), the process flow (the browser's swimlane and Mermaid), detailed steps (who / when / how / output, one per table step in order), exceptions and edge cases, metrics (with the engine's lead time and rolled %C&A quoted as baselines) and related documents. Verdict: audit_ready | needs_detail | not_documentable. Handoffs: "Document the future state" writes the browser-built future-state table into the form and switches to the document lane with a note that it supersedes the earlier version; "Find the waste in this process" runs the improve lane over the same table. Every number the model writes is read back against the engine and the user's own text; a number in the future-state prose is a disagreement by definition; rejected operations count as disagreements; the improve verdict must equal the engine's posture; the SOP must cover every table step exactly once. Disagreements are shown next to the result. ## The contract Run body: `{ "task": "improve" | "document", "process_name": string, "description": string, "steps": string (the table as pasted, clipped on whole rows), "demand_per_week": string, "future_note": string (document only, optional), "facts": string }` where `facts` is the JSON the browser engine computed: `Flow.facts(Flow.parseSteps(table, calendar), {process_name, demand_per_week})` from flow.js, which runs in Node with `global.window = {}`. The reply is one JSON object with `lane`, `title`, `headline`, `verdict`, `summary`, `notes_on_input`, `risks`, `next_steps` and the lane body (`current_state`, `wastes`, `changes`, `future_state`, `impact`, `implementation_plan` for improve; `process_name`, `owner`, `review_cadence`, `purpose`, `scope`, `raci`, `steps`, `exceptions`, `metrics`, `related_documents` for document). Full field list and worked examples: https://process-desk.skillsafe.ai/api.html ## Sources Derived from the agent skills @anthropics/process-optimization (https://skillsafe.ai/skill/@anthropics/process-optimization/) and @anthropics/process-doc (https://skillsafe.ai/skill/@anthropics/process-doc/), both from the operations plugin of anthropics/knowledge-work-plugins (Apache-2.0; licence text and a note of the changes at https://process-desk.skillsafe.ai/LICENSE-ANTHROPICS-KNOWLEDGE-WORK-PLUGINS.txt). The engine's definitions are Martin & Osterling, Value Stream Mapping (McGraw-Hill, 2014) and Little's law (J. D. C. Little, 1961; Hopp & Spearman, Factory Physics). The RACI rules are the standard responsibility-assignment guidance (exactly one Accountable, at least one Responsible per activity). The engine was verified against an independent Python implementation written from those definitions on 2,000 random processes with future-state operations (29,646 checks, 0 disagreements), with three wrong-definition controls that must and do disagree: an activity ratio that ignores waiting, a rolled %C&A taken as an arithmetic mean, and a parallel group summed instead of taken at its longest member. Not affiliated with the skills' authors or the books' publishers. The desk does not know your organisation: what it says about roles, controls and exceptions is only as good as what you paste.