Turn operations, observed.

AMH manages single-family rental homes at national scale. Every tenancy that ends triggers a Turn: inspecting the vacated property, identifying and scoping work, coordinating technicians and vendors, approving costs, completing repairs and returning the home to market.

The operational target was demanding: market-ready within 10 days of the move-out inspection.

But that lifecycle did not exist inside one product. Work and information were distributed across 4Services and 4Enterprise, Primo for inspections, Power BI for property status, and communication channels such as email, text and phone. Moving a property through Turn meant moving between systems too.

The platform was already live. Much of the day-to-day workflow, however, had not been tested closely with the people carrying it out.

The discovery ran over four days, including two days on site in Greensboro. I observed two Field Turn Technicians working in vacant properties and two Field Managers coordinating Turn work from the back office.

Rather than relying on retrospective interviews alone, I wanted to see where the work actually happened: how technicians moved through inspections and property access, how Field Managers planned and coordinated Turn activity, which products were involved, and where people compensated when the tools did not support the job cleanly.

The research covered both sides of the workflow. In the field, I observed how technicians used Primo and the wider toolset while moving through properties, inspections and follow-on work.

In the back office, I observed how Field Managers combined Work Orders, reporting, inspection data and external communication to understand what could move next.

Across the sessions I captured observations, then grouped and compared them through thematic analysis. The goal was not simply to catalogue usability issues, but to trace:

what happened → what it revealed → what kind of response the evidence justified

The Greensboro research produced five recurring themes:

• UX issues and missing functionality
• time-consuming manual tasks
• performance and connectivity
• lack of integration
• training and process clarity

Taken individually, they looked like a mixture of usability problems, workflow inefficiencies and technical constraints.

Looking across them, however, I found a more useful distinction: where was the breakdown actually occurring?

Some problems sat at the decision level — the information existed, but was hidden or dispersed when someone needed to act. Others sat at the workflow level, where people compensated for product gaps through manual steps and workarounds. Others were system-level, created by breaks between products, data and handoffs.

Performance, connectivity and training cut across those levels rather than fitting neatly into one. Slow or unstable connections could disrupt otherwise sound workflows, while unclear product behaviour and process knowledge could overlap.

This distinction helped prevent every finding from becoming a UI redesign. A visibility problem, a broken workflow and an integration problem might all create friction for the same person — but they require very different responses.

Not isolated to Greensboro

The same broad themes had appeared in earlier research in Orlando.

That did not make the Greensboro sample representative on its own, but it gave us an important additional signal: several of the problems were not unique to one market or one group of participants.

The overlap increased confidence that issues such as manual work, fragmented systems and product friction were worth investigating beyond the immediate Greensboro context.

A Field Manager’s job was to keep properties moving through Turn while protecting the 10-day market-ready target.

That meant continually deciding what could move next, what work could be assigned, and whether there was enough context to commit the work confidently.

The difficulty was that the Field Manager had one operational decision, while relevant context could be distributed across several products and communication channels.

Work Orders held details, issues, notes and resident information. Power BI provided property and move-out status. Primo held inspection, remedy and approval context. Resident and vendor communication could continue through email, text and phone.

No single interface brought all of that context together around the scheduling decision.

This did not mean every scheduling decision required every system.

The problem was that the product boundaries did not consistently match the decision boundary. Depending on the work, Field Managers could need to cross-check different parts of the wider product environment before they were confident enough to move a Turn forward.

Where the friction appeared

Scheduling context

Important Work Order information was spread across tabs, making it harder to judge an assignment from one view.

Resident communication

Contact and scheduling conversations often moved outside the platform into email, text or phone, leaving part of the operational context outside the core workflow.

Recurring work

Repeated technician activities and market-specific tasks could require manual recreation rather than being represented cleanly by the product.

Inspection and vendor handoffs

Detailed field-inspection information lived in Primo, while vendor coordination could happen outside the core systems. This made the overall state of a Turn harder to reconstruct.

One small interaction made the problem tangible

One finding captured the broader issue particularly clearly.

The resident’s preferred visit time already existed on the Work Order, but the Field Manager had to hover to reveal it while scheduling.

The issue was not missing data. It was decision-critical information that was insufficiently visible at the moment of action.

The recommendation was to surface the preferred visit day and time directly in the interface. It was noted for a later design phase rather than implemented during my involvement.

Before the Greensboro fieldwork, I had a high-level working model of the Turn Technician’s day based on existing product and organisational knowledge.

It captured the broad journey:

Start day → Travel → Access property → Carry out Turn → Diagnose → Finalise Turn

Direct observation confirmed that overall structure, but it also made several underrepresented parts of the role explicit.

Technicians were working through low-connectivity environments, moving between more systems than the initial model showed, handling lockbox work, travelling for parts and materials, and in some cases continuing into self-performed Work Orders after the inspection itself.

The point was not that the original model was wrong. It was that field observation made the boundaries of the role more complete.

The updated model gave subsequent product discussions a stronger basis in observed work rather than assumptions about how the technician role operated.

Looking at individual roles explained where friction appeared locally.

I also needed to understand how those problems connected across the full Turn lifecycle.

I mapped the process from move-out inspection through internal coordination, vendor work, approvals and completion, showing where responsibility and information moved between people and systems.

The map made one structural issue particularly visible: the operational process was continuous, but the supporting information was not.

What the map revealed

Field inspection

Primo held detailed information about property conditions, issues and remedies at the point of inspection.

A system break downstream

That inspection detail did not flow cleanly into 4Services, leaving downstream teams with a more limited view.

Vendor coordination outside the core products

Some handoffs moved into phone, text and email rather than remaining visible inside the operational system.

Operational reconstruction

Because context and status lived across several systems, Field Managers sometimes had to combine those views themselves to understand overall Turn progress.

The important point was not one isolated usability issue. It was that the lifecycle crossed product boundaries more often than the user’s task did.

The Greensboro study was a focused discovery engagement, but the findings were not useful as a one-off research readout.

I translated the evidence into clearly framed product questions and next steps, separating issues that were understood well enough to act on from those that still needed design exploration or broader technical and organisational investigation.

That distinction mattered because the research surfaced very different kinds of problems. A hidden piece of scheduling information could have a relatively direct response. Integration between Primo and 4Services, by contrast, could not responsibly be reduced to a UI recommendation.

The research therefore became an input into continuing product conversations rather than a single prescribed redesign.

I carried the findings into subsequent discussions so that later design work could be traced back to observed behaviour rather than treated as disconnected feature requests.

The research did not point to one redesign.

Instead, it clarified how far the evidence allowed us to go.

Some problems were understood well enough to define a clear next step. Others established a meaningful product problem but still required further discovery and design. The most structural findings crossed product, technical or organisational boundaries and needed broader investigation.

The distinction helped prevent every research finding from becoming an immediate design recommendation.

Examples such as preferred visit time or missing Power BI data had relatively clear next actions. Issues around the wider Work Order experience, resident communication or recurring tasks needed deeper product design. Integration, application consolidation, vendor participation and connectivity were larger questions that could not be resolved responsibly through interface changes alone.

Findings were raised with the relevant product, design and data stakeholders and informed subsequent discussion around the Turn experience.

Reflection

Researching where the product stopped matching the work

The study reinforced that observing a live operational product is rarely just about finding usability issues.

The most useful findings came from understanding where the product stopped matching the work: when important information was hidden at the moment of decision, when people compensated through manual processes, and when the user’s workflow crossed boundaries between systems that the organisation treated separately.

The sample was deliberately small — two Field Turn Technicians and two Field Managers — so I would not treat Greensboro alone as representative of every market. Seeing similar themes in earlier Orlando research increased confidence that several of the issues were worth investigating more broadly.

It also changed how I thought about research recommendations. The right output was not a list of features. It was an evidence-based judgement about: