Change Order Management
30% of property transitions between tenants need a change order to the original scope, and those changes were tracked by hand. I designed one system across five platform surfaces, starting with the data model.
Roofstock is a real estate investment platform for buying, managing, and selling rental properties. Its property management arm, Mynd, is a full-service management company handling tenant placement, maintenance, rent collection, and day-to-day operations for thousands of single-family rentals across multiple markets. An internal operations team coordinates the inspections, repairs, vendor work, and owner approvals that keep those properties occupied.
When the Scope Changes, Everything Slows Down
Every turn begins with an approved scope and a budget to match it. Both are estimates until a vendor is on site.
A “turn” is the process of getting a property ready for the next tenant after one moves out. It goes through five stages, all managed by a Construction Specialist (CS). A change order happens when the actual work differs from the approved scope. This could be when a vendor goes out to fix a sink and finds water damage to the cabinet, a line item needs a different material, or work that was scoped turns out to be unnecessary.
A third of turns need a change order since scope is estimated until a vendor is on site. Each one adds around two days to the turn, and on average increases costs by a few hundred dollars. On a single property that may be minor, but across thousands of properties, it’s added operational cost.
We had no system in place for managing change orders. There was no structured intake, no decision workflow, no approval routing, and no way to view change order status.
The process worked because people made it work, not because the system supported it.
Vendors who needed to submit a change order either called, texted, or emailed the CS, who then tracked the request by hand. If the CS didn’t loop in the property manager, owners found out about scope changes when the costs appeared in their distribution statements, sometimes weeks after the work was done. One CS summed it up: “It’s pretty manual.”
Change orders touched multiple surfaces. The vendor portal where requests originate, the internal workflow system where CSs review and decide, the work order and line item view where the data lives, the service request view where cost accumulates across the turn, and the owner portal where owners approve costs above their threshold. Each surface served a different user with a different need, so designing any one of them in isolation risked the others falling out of sync.
The Same Data, Viewed Five Ways
Discovery didn’t reveal a hidden problem. The issues were well documented, the data was clear, and stakeholders had a solid idea of what needed to happen. But “change order management” described a concept, not a design. Turning it into a working system meant answering questions nobody had to consider while the process was manual.
Early sessions with stakeholders focused on:
Change orders resolve alongside the turn, not back through it.
In one of those sessions we decided that resolving a change order should run parallel to the turn instead of sending it back to the scope stage. The existing mental model was sequential, and switching it meant a turn could keep moving while a change order was being resolved. Most of the system’s structure was built on top of that decision.
Each surface answered a different question. A vendor needed an up-to-date to do list. A CS needed context to make informed decisions. A property manager needed a simplified, recommendation-led view to approve or escalate to owners. An owner needed financial clarity and enough context for contribution requests. The audit trail needed all of it preserved.
Five views into one shared model instead of five features stitched together.
We separated what the system stores from what’s visible to the user. The system would house all information related to the change order, and the UI would show only what that person needed. Nothing is deleted. A removed line item, a superseded price, a rejected request all stay in the record, out of the way of the people who don’t need them. That is what lets the audit trail be complete without making any one screen carry it.
Not shown
Designing for Mixed Outcomes
The design phase was planned to take two weeks. Once I started mapping the surfaces, it was clear that two weeks would only cover the vendor portal. I outlined the full design scope, surface by surface, and made the case for extending to roughly a month so I could work on the whole system. The extension was approved.
One record that all five surfaces pull from and read the same way.
The structural decision was to attach a change order to the whole turn rather than to any single work order. One change might affect items across several work orders at once, and tying it to one would have made the true cost of a turn impossible to see as it changed. Every line item also keeps its full history instead of being overwritten, so the system can show both what’s true now and how it got there.
The behavioral decision was the lifecycle, a full set of states a change order moves through from vendor submission to resolution. I mapped every state and transition, since all five surfaces would depend on them. Each screen is a different view onto the same states, so a change order that’s “under review” reads the same way whether the vendor, the CS, or the owner is looking at it.
A vendor submits a change order, and it waits under review until the CS makes a decision. If the cost falls under the owner’s threshold, that decision is final. If it goes over, the property manager reviews it and either approves it or sends it to the owner for approval. Once approved, the accepted work becomes line items on a work order and the change order closes.
The entry point was a type selection: add new work, modify existing work, replace line item, or remove existing work. The form collected justification, photos, and cost, with validation against the library’s typical range. The type drives everything downstream, so asking for it first keeps the vendor from describing a replacement as a new item. Validating cost at submission means the CS is reviewing a number that is already in range, rather than sending it back.
Every result is one item becoming either a to-do or nothing.
The hardest thing to represent was a bulk change order with mixed outcomes. Picture a vendor with a 10-item work order who submits a single change order requesting two new items, a modification to one existing item, a replacement of another, and a removal of a fifth. The CS accepts the new items, the modification, and the removal, but rejects the replacement. How does that resolve in the vendor’s line item list, which they use as a daily to-do list?
The answer was to keep the vendor’s main list intact and use statuses instead of shuffling items between sections. Any item with a pending change order, whether it’s being modified, replaced, or removed, stays in the main list but carries a “change order” status. Below the list, a Change Order section shows every requested change (add, modify, replace, remove), marked under review. The vendor can see what’s pending without losing sight of the work in front of them. That model worked because the vendor’s list only ever resolved into things they actually need to do.
When the CS acts on a change order line item, it has one of four outcomes, accepted, reassigned (accepted but given to a different vendor), modified (accepted with changes), or rejected.
An accepted modification or replacement updates the item in place and flips its status to “to do.” An accepted addition appears as a new “to do.” An accepted removal, or an item reassigned to someone else, drops off the vendor’s view entirely. A rejection returns the item to “to do,” unchanged. The only case with nothing to show is a rejected addition, since that item never entered the list. Each line item resolves on its own, so a bulk change order with mixed outcomes needs no special handling.
Review happens where the CS already works.
CSs work out of the service request’s turn view, so that’s where the review lived instead of another page in the product. I added a Change Orders section to the service request that expands into a table of every change order on that turn, with columns for type (add, modify, replace, remove), line item name, who submitted it, the date, and the review status across each stage that applies.
Accepting means deciding where the work goes: update the original work order, add it to another, or create a new one with the same vendor or a different one. Replacements carry one more decision, whether to keep the original line item (when the vendor already did billable work on it) or remove it. Modifying lets the CS revise the change order before it goes through. Rejecting sends a reason back to the vendor.
Not every change order needs owner approval. Below the owner’s auto-approval threshold, the CS’s decision is final. Above it, the change order routes to the property manager, who can approve it or escalate to the owner.
Deciding per item respects that it’s the owner’s money.
When a change order does need owner approval, it surfaces in the owner portal dashboard under Approvals. The owner reviews it line item by line item, approving or declining each new or modified item. Removals appear too, with the credit the owner will receive, for visibility rather than as a decision. A summary shows the price breakdown based on those decisions and the funds needed to move forward, so the owner knows what they’re paying for.
Property manager review and owner approval were deferred to a later release, so above-threshold change orders stayed a manual process until then. Analytics, vendor trust scoring, and advanced features were pushed too. The cost of that was leaving the approval chain unbuilt for a release. What we got in exchange was shipping vendor intake and CS review first, which started capturing structured data and cut the most frequent manual work while the rest came later.
Turning a Manual Process into Data
The project is in development, so these are targets rather than shipped results. Each one is tied to a specific problem in the current process and measured against the baseline we pulled during discovery. These are the numbers I’d hold the work accountable to.
The design also makes things possible that weren’t before. Every change order now leaves an audit trail and builds a dataset the company didn’t have. None of it needed a separate reporting effort, only a record that existed in the first place.
The most complex parts of the system are the least tested.
I wanted to test the vendor submission flow and the bulk change order experience with real users before engineering started, but the timeline didn’t allow for it. The bulk change order with mixed outcomes is the most complex interaction in the system, and the one most likely to need revision. On the owner portal, I’d want to validate the two-step flow with real owners before investing further in it. Line item level review is the right model, but how much detail and framing an owner needs to approve confidently is an open question, and I designed it without testing that assumption.