Sweep
Turning a signed cleaning contract into a launch-ready operation.
Sweep helps commercial cleaning companies launch and operate client sites. I redesigned the site-creation workflow so an operations manager can move from basic property details and a signed contract to an approved service plan, a staffing recommendation, and a launch-readiness checklist. The central challenge wasn't data entry — it was helping the operator interpret contractual requirements, resolve uncertainty, and make accountable operational decisions without losing the original source.
“Adding a site” is actually a chain of operational decisions
A newly signed contract doesn’t create a record — it creates a dependency chain. Each link relies on the one before it, and a wrong call early quietly breaks everything downstream.
The operator isn’t entering information. They’re translating legal and commercial commitments into a system that people must execute every night.
Framing the workflow before drawing it
This was a time-boxed assessment, so I used product analysis, operational workflow mapping, and design assumptions rather than claiming primary user research. The framework below identifies what would need to be validated with real operations teams (see the proposed validation plan).
The same site information is re-keyed across a chain of disconnected tools — every hand-off is a chance to drop a requirement.
These framing artifacts are design assumptions, not findings. See what a first study would test in Section 12.
The difficult part is not extracting the contract. It’s turning uncertain language into accountable operational decisions.
A system can identify hours, zones, labor, and access terms — but those findings shouldn’t silently become the operating plan. Sweep must show what came directly from the source, what was inferred, what is uncertain, and what the operator approved.
Four rules the workflow answers to
One workflow, with a clear line between system and human
Sweep analyzes and recommends; the operator reviews and approves. Every automated step hands off to a human decision before it becomes real.
The workflow begins by earning permission to automate
Before analysis runs, Sweep sets expectations: it states what it intends to extract, keeps a draft saveable, and makes error recovery a first-class part of the flow — not an afterthought.
Every extracted finding stays editable and attributable
Analysis produces a reviewable ledger, not a finished plan. Findings that were inferred — a service window read from “evening hours,” a labor estimate over contracted hours — are flagged with confidence and consequence, and each one is editable before it’s used.
A single hierarchy repeats across every extracted item
Example: §3.1 says “evening hours.” Sweep infers a 6:00 PM–12:00 AM window, flags it low-confidence, notes the consequence (“confirm before staffing”), and waits for the operator to confirm, edit, or ask the client — with the decision written back to the source.
Recommendations show the cost, quality, and coverage trade-off
The estimate runs 2 hours over the 36 contracted — so Sweep lays out three responses side by side: add weekly hours, reduce a low-priority task’s frequency, or accept overtime exposure. Each option spells out its consequence; one is marked Sweep recommends, but none is applied without approval.
Source preserved: the original contract text and Sweep’s inference stay attached to every override, so the audit trail survives the operator’s edits.
The approved contract becomes a plan that can still be challenged
The generated plan isn’t a black box. The operator can inspect zones, task counts, frequencies, weekly labor, equipment, access notes, daily distribution, and nightly crew capacity — across three views of the same 36 hours.
Zone plan. The weekly total fits the contract (36.0 / 36.0 h) — yet a banner still warns that one night exceeds crew capacity.
A plan must be feasible at more than one level
The takeaway. The weekly total can fit the contract while a single night still exceeds crew capacity. Sweep evaluates both total labor and daily feasibility — matching the contract total doesn’t guarantee the plan works each night.
Values reconstructed from the prototype to illustrate the design intent — not measured production data. The red mark shows the 7.6 h/night capacity a compliant weekly total can still breach.
Approved. Sign-off carries the plan’s decisions forward and unlocks staffing — the plan stops being editable-in-place and becomes the launch baseline.
Planning is incomplete until the right people can execute it
Staffing recommendations weigh role, availability, certification, experience, travel time, weekly hours, overtime risk, and coverage gaps. Crucially, Sweep exposes its imperfections rather than hiding them.
Candidate comparison. Assigning a role opens a drawer that compares candidates on the exact factors the recommendation used — availability, certification, experience, travel, hours, overtime.
Then staffing connects to launch readiness
Security badges, loading-dock procedure, client walkthrough, team acknowledgements, client dependencies, overdue blockers, and monitored launch risks all become tracked tasks — carried forward from the decisions before them.
Designing for the ways document analysis and plans fail
Sweep can organize evidence, surface risks, model trade-offs, and recommend actions. It should not silently approve contractual interpretations, make irreversible staffing decisions, or hide uncertainty from the operator. The human stays accountable; the system stays legible.
What I’d test before trusting the workflow
No testing has been run. This is a proposed plan — 5–7 commercial-cleaning operations managers, site-launch coordinators, or workforce planners, think-aloud on the prototype.
What designing an accountable operations workflow taught me
Automation should expose its seams. The product is more trustworthy when users can see exactly where extraction ends and inference begins — the low-confidence flag is a feature, not an apology.
Enterprise workflows are decision systems. The most important work wasn’t styling the dashboard — it was structuring how risks, approvals, dependencies, and consequences move through the product.
A plan must be feasible at more than one level. Matching the weekly contract total doesn’t guarantee the staffing plan works each night; the workflow has to check both.
Source preservation changes behavior. Keeping contract language attached to every override encourages careful decisions and creates an audit trail worth trusting.
The workflow should end in action. A useful operations product doesn’t stop at analysis — it converts the approved decision into schedules, staffing requirements, messages, tasks, and launch readiness. If I continued, I’d run the validation plan above, starting with T3, the fact-vs-inference comprehension task the whole concept depends on.