AMH is a large US single-family rental operator. When a resident moves out — whether the lease simply ended or they were evicted — and still owes a balance thirty days later, the account moves to collections. A small team then has to do something genuinely hard: hold sensitive payment conversations with former residents and recover money, fairly and accurately.

The system never gave them a clear place to do it. There isn’t even a real “collections” status — it’s inferred from the move-out reason held in the property system. And the information needed to work a single account is scattered everywhere: the worklist lives in the CRM, the true balance and ledger live in Yardi, the documents live in Yardi attachments, the resident-manager and legal notes live in memos, the weekly account list arrives as a spreadsheet from accounting, and email replies only ever reach Outlook.

So every call begins with reconstruction. Before an agent speaks to anyone, they cross-check the CRM against Yardi to confirm the balance is even current, hunt through attachments for the documents that matter, and read memos to piece together what’s already happened. The collections lead put the goal in a single line — “if I can marry CRM and Yardi, I’d be one happy camper.” That sentence became the brief.

The work began with a discovery session with the collections lead — an hour spent walking through how an account actually moves through the team, one system at a time. I didn’t run that session; my role was what came after it. I took the raw discovery and synthesised it into something the team could design against: a clear problem map, and the personas and journeys underneath it. In practice that meant separating what the tools genuinely supported from the workarounds people had quietly built around them, and grouping the friction into a handful of real problems rather than a long list of complaints.

The direction itself wasn’t mine to claim — bringing CRM and Yardi onto one screen came straight from the room, and the lead wanted it before I drew anything. What I owned was making it real: defining who we were designing for, mapping how they actually work, and designing the workspace that delivers on it.

A note on how this was made, because the method is part of the point. The work was AI-assisted, with a human checkpoint at every stage. Claude analysed the discovery transcript and drafted the first synthesis; I then listened to the recording myself and corrected that draft against what I’d actually heard, so the themes answer to the session rather than to the model. The wireframes were generated with Figma Make and reworked by hand wherever the flow, the data or a detail needed it. The acceleration was real — but the judgement, what mattered, what to keep and what to change, stayed mine.

Collections isn’t one job. The synthesis kept surfacing two distinct roles with different goals, different tools, and different points of failure — and any workspace had to serve both without splitting into two products.

The two roles meet the same account from opposite ends. The administrator needs oversight and a clean way to distribute work; the agent needs one trustworthy place to do it. That tension — one shared account, two very different jobs — set the shape of everything that followed.

Following one account through the process shows why the fragmentation bites. An agent picks an account off a marketing list in the CRM, then leaves it almost at once — the CRM holds the worklist, but not the truth. To check the balance is even current, they move to Yardi for the ledger, the move-out date and notice type, the attachments, and the memos that explain what’s already happened. Only then can they call. As they talk, they type the notes back into the CRM by hand; if the resident replies later, that reply lands in Outlook and never reaches the account.

Upstream, the administrator’s day starts in a spreadsheet. Accounting sends a weekly Excel of balances due — evictions and non-evictions split apart — which is scrubbed, uploaded into the CRM as marketing lists, and handed out one account at a time. From that point the list is never revised, so balances drift: a resident may have already paid, had a concession applied, or had a stop placed on the account. Oversight is whatever can be pieced together from the activity logs.

The shared cost is reconstruction. Before anyone can do the real work — talk to a person about money, accurately — they first have to rebuild the account’s story from pieces held in four different places.

To see where the fragmentation actually bites, I mapped each role’s journey end to end — the stages they move through, what they do at each, the systems they touch, and where it breaks. The colour coding tracks which system owns each step (Yardi holds the truth, Dynamics CRM the worklist, Excel and Outlook the parts to be replaced) and grades each pain point critical or moderate. A final row sets out the proposed response, stage by stage.

Read across, one pattern dominates: the pain concentrates at the seams — wherever a role has to leave one system for another. For the administrator that’s a manual Excel handoff, no live view of recovery, and reporting stitched together by hand; for the agent it’s constant CRM-to-Yardi toggling, calls and emails that never reach the case, and a promise-to-pay that survives as a manual document. Every critical point traces back to the same root — and the “proposed” row is that one answer expressed in each role’s language: the unified workspace.

The problems pointed to one answer, and the principles fell out of them directly. The workspace had to:

The direction was confirmed early. When the single-screen view was put to the collections lead, the response was unambiguous — “your vision is exactly my vision.”

The administrator’s job is to get the right cases to the right agents and keep the whole operation in view. The flow is built around distribution and oversight — with the weekly spreadsheet and the guesswork taken out. Figures shown in the screens are illustrative prototype data.

The assignment step is where the design’s stance on AI shows itself: EliseAI proposes, with its reasoning on screen, but the administrator makes the call. Automation that speeds the work without taking the decision. From any list, the administrator can drill straight into the unified case view shown at the top.

Where the administrator distributes and oversees, the agent works the account — and the flow is built so they never have to leave it. Figures shown in the screens are illustrative prototype data.

Everything that used to mean four systems — the call, the ledger, the agreement, the record — now happens in one place. The reconstruction is gone.

The client already used EliseAI — a conversational AI tool — elsewhere in their operation, and wanted to see where it could help here. Collections is exactly the kind of work where that takes care: the conversations are sensitive, the money is real, and a wrong automated assumption has consequences. So the principle was simple — let AI take the repetitive groundwork, and keep people on every decision that touches a resident.

The deliberate choice was restraint. AI earns its place by removing the drudgery around the work; the judgement, the negotiation and the call to a real person stay with the team. Accelerate the groundwork, never automate the conversation — and put a human approval step wherever the AI makes a suggestion that affects someone.

A concept is only as honest as the things it can’t tidy away. A few are worth naming.

And the honest ending: this was a discovery-led concept. The flows for both roles were designed and validated in principle with the people who do the work, but the idea was parked — the client chose to prioritise other areas before building it. The value here is the thinking and the design, not a shipped result.

The hard part wasn’t drawing screens. It was taking a sprawling problem — two roles, four disconnected systems, a process held together by spreadsheets and a misused “birthday” field — and deciding what one workspace had to be to make it coherent.

It was parked before it was built, and the case study says so. But the judgement it took to get from a fragmented, four-system reality to one defensible workspace — that’s the part that travels to the next problem.