Closing the gap between the ticket and the conversation

HappyMaintenance, HappyCo's maintenance platform, had a fundamental communications problem — and it wasn't one that could be solved by adding features. The platform integrated with dozens of property management systems and resident portals, each built to work with their own maintenance solutions. Information moved across these integrations imperfectly: only what each system chose to expose was available, and what came back was equally constrained. The result was that everything outside the ticket itself — scheduling, follow-ups, permission to enter, resident updates — happened somewhere else, in systems that weren't designed for it.

For technicians, coordinators, and residents, this showed up as constant friction. Techs had no way to message a resident about arrival time. Coordinators following up on a ticket had to move between systems to do it. Residents received communications through their building portal, if they received them at all. The ticket and the conversation were completely disconnected.

I was brought in to lead a new team — ResTech — focused on closing that gap.

The central insight was that we couldn't fix the integration layer, but we could route around it. Rather than relying on resident portals we didn't control, we built single-use resident portals that lived inside our system. Residents received a link by text or email, clicked through without creating an account, and could add details to their ticket, message a coordinator, or give permission to enter their unit. Everything they submitted fed directly back into HappyProperty — no manual entry, no system-switching. For the first time, the conversation and the ticket were in the same place.

Resident notifications became a central part of Happy Maintenance, allowing teams to effectively communicate with residents throughout the ticket lifecycle.

In parallel, we tackled HappyForce — HappyCo's remote maintenance technician service, where the goal was always to increase the ratio of techs to residents. The work here was less glamorous but meaningful: cleaning up inefficient database queries that were slowing the platform down, and fixing UX problems that required techs to keep several windows open at once just to do their jobs. Small things, but the kind that compound.

The AI work came out of the same throughline. Maintenance tickets are often long and hard to parse — transcribed voicemails, fragmented notes, incomplete descriptions. Nobody in triage has time to read through all of it carefully. We shipped AI-powered maintenance summaries globally, giving coordinators and triage staff a clear, readable summary of what was actually wrong without having to dig through the raw ticket. Early for that kind of feature in a B2B product — this shipped in early 2024.

AI-generated ticket summaries ensured that complex tasks could be understood at a glance.

We also developed a pilot for AI-assisted triage, designed for HappyForce technicians who handle the first pass on incoming tickets. Triage tends to involve the same questions asked repeatedly to make a ticket actionable. The tool provided a suggested next question and a scaffold to ensure techs collected the minimum information needed to act — faster throughput, fewer gaps, better signal for whoever handled the ticket next.

The resident communications portals moved into customer pilots during my time, with refinement continuing after I moved on from the company. It has become a core selling-point for the Happy Maintenance product. The AI triage pilot was the internal HappyForce team with consistent improvement before being fully deployed. Alongside improvements made to system performance and UX, HappyForce technicians reduced time on task by roughly 18% - an astronomical change. The AI maintenance summaries shipped globally and are live in the product. Across all of it, the throughline held: reduce friction for the people touching tickets, and the whole system works better.