Designing a closeout workflow crews would actually use

A defect fails mid-inspection on the phone. The desktop punch list goes four to five, and the phone never leaves the form.

At a glance

Role Product designer, Sitetracker construction — third designer on punch

Scope Entry point · routing · acceptance workflow · mobile parity

Team A PM, a tech lead, web and mobile engineers

When Early 2025 to January 2026

Outcome 333 people opened punch creation on a phone, April 2025 to July 2026 — every customer, in a window running six months past my handoff

The feature existed. It was being done at a desk.

Every construction site closes out on a punch list: the defects it must clear before anyone accepts the work. Sitetracker shipped punch, ownership lapsed, my team picked it up in 2025.

Punch was not unused. A March 2025 snapshot counts over a million punch operations across the install base, though it defines neither an operation nor the surface. Mobile is where it is small: at one account, over three months, two active users. The heavy usage was somewhere, and it was not on a phone.

Punch was built as a destination. Defects are found in forms.

Punch shipped as a central list you navigated to. Nobody discovers a defect on a list — they turn up mid-inspection, and an inspection is a form. A punch item is a failed checklist answer.

You could already create one from a form. Almost nobody knew, and the path re-asked everything you had just typed.

Fixing the destination — filters, search, a better list — would not have moved anyone; it still asks a crew to stop and go elsewhere. Working through mobile usage with the forms designer, I judged the entry point the larger gain for the smaller build.

One action now creates the item from the failed entry, carrying subject, comments and photos. I specced the count on the form item as a link back in and out — the round trip that would collapse two destinations into one.

The failed checklist item, carrying a punch count of one.

Created from the failed form entry; a punch manager assigns at the desk.

Contractors find most defects, so they should not set priority or ownership: they create, a punch manager assigns from a desk. Forms is also how operations and maintenance run scheduled inspections, so punch became reachable by a business line nobody had scoped it for. I flagged that and left before anyone sized it.

Punch is not a list. It is a gate.

A telecom-tower operator's acceptance policy showed me the model underneath. They were forecasting 80,000 punch items a year across 20,000 sites. Defects are scored, and once the total crosses a threshold the site cannot be handed over — a rule that decides whether the business gets paid.

I modeled six statuses, naming the owner on every transition a person can trigger. Critical defects carry 72 hours, major and minor 20 business days. I specced the clock to pause on hold but continue without reset on reassign, so nobody buys time with a handoff.

Their policy scores minor defects 1, major 2, critical 6, and six points blocks handover: one critical defect stops a site.

The six states I modeled, an owner on every transition a person triggers. On Hold and Reassigned never shipped, and it shows — neither has a specified exit.

Four of the six shipped.

The control I liked died in an internal demo.

The fix-review screen used an approve-or-reject toggle, a reason field, and a separate Submit. My PM went straight to submit, missed the toggle, got stuck. "This kills me, Molly." My tech lead proposed what shipped: two buttons, no submit. I conceded the confirmation step and pushed for undo in the toast — an accidental reject is recoverable, a missed toggle is not.

The version that failed. Review Status is required but easy to skip, and Submit sits below the reason field, so a reviewer who goes straight for it never sets a verdict.

Crews could not create a punch list on a phone.

"I cannot create punch lists on my phone… I tried it several times to do it via my phone. It didn't work."
— field rep, EV-charging network

Mobile showed only the most recent fix attempt, and rendered Approve and Reject to whoever submitted the fix — a self-approval hole in a model whose hard line is that nobody approves their own. I treated both as P0s and settled the fallback up front with the mobile engineer: if carrying the list name forward was too expensive, users would rename once so every item landed in one list. The fix timeline was in verification at handoff.

The fix screen carries the prior rejection with its reviewer, reason, and retry count.

333 people opened punch creation on a phone.

A teammate's GA4 pull, April 2025 to July 2026: 333 active users on the create-punch-item screen — the one this work was built around. A European operator is rolling punch across four countries after migrating off a competitor; the account note credits the punch work, though I cannot separate it from the migration.

I will not call that a result. Mobile usage lived in Firebase, web in Salesforce analytics, and neither defined when a punch item was created, so GA4 counts screen opens. Every number here stops at creation.

What I should have written first: one event, fired once on a successful create, carrying the surface and path.

Every transition on that diagram is owned by a person. Agent workflows are not — a state changes because a model decided something, sometimes wrongly, with nobody watching — which is why the reject control is the piece I reach for most. Recoverable over preventable, because the cost of being wrong runs one way.