Moving quality checks from the desk to the field

Punch launched, but it never got used in the field

Every construction project closes with a punch list: issues the crew must fix before closeout. Sitetracker released Punch, ownership lapsed, and my team took it over in 2025.

Mobile use was rare. On one account, only two people used Punch on their phones in three months. The work was happening at a desk. I rebuilt mobile punch creation and the fix-review flow.

I met crews where the work already happened

Defects are found during inspections, in a form on Sitetracker mobile. A punch item is a failed checklist answer. Users could already create a punch item from a form, but few knew, and the flow re-asked everything they had just typed.

I reviewed mobile usage with the forms designer and prioritized redesigning the entry point before better filters or search.

With the mobile engineer, I settled a fallback. If carrying the list name forward was too expensive, users would rename the list once so every item landed in it.

The failed answer becomes a punch item, and the form marks it.

I ran five customer sessions across three operators.

I specced the punch item count on the form as a link, so crews can tap through to the item and return to the inspection.

Contractors find defects; punch managers assign them at a desk. Anyone could approve their own fixes, so I narrowed approval to two roles, punch item manager and fix assignee. Both roles inherit from the punch list down to each item.

I used a second business line to win priority

Forms also run scheduled maintenance inspections, so punch followed. I argued punch up the list because it was the only work touching a second business line.

Our largest new customer used Sitetracker only for maintenance. I worked out the routing with their team and my tech lead: a punch item becomes a corrective-maintenance ticket, and jobs hang off that ticket, each routed to a named person or vendor.

The punch list determines when a customer gets paid

A telecom-tower operator was forecasting 80,000 punch items a year across 20,000 sites. Defects are scored: minor 1, major 2, critical 6. Six points blocks handover, so one critical defect stops a site.

I designed six states, with an owner for every transition a person triggers.

On Hold and Reassigned never shipped.

The demo killed my preferred control

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

This version did not work. What shipped: two buttons, no Submit, and undo in the toast.

I put each person's items on one list

The inherited list split punch items across status tabs, and every row repeated its ID, list, and assignee. I merged the tabs into one list and gave each row one reading order, the issue first, then due date and priority, then status. Status sits under the title because punch titles run long and translations run longer.

The inherited design, beside my unified list.

The mobile fix screen hid its own history

I cannot create punch lists on my phone… I tried it several times to do it via my phone. It didn’t work. — Senior manager

On mobile, users only saw the latest fix attempt, and both Approve and Reject were available to whoever submitted the fix. That let a contractor approve their own work. I prioritized both.

Over sixteen months, 793 people used punch lists on phones. That shows reach, not lift. Mobile creation never got the success event I should have specified.

Outcome

Crews log a defect where they find it, without retyping the inspection.

Four of six designed states shipped, including the cancelled status three customers asked for.

A French EV-charging operator adopted punch nationwide, expanded to three more countries, and left a competitor.