• By Dan Mintz. 3x founder, Wharton MBA, MIT MS in Machine Learning.

• Leading enterprise AI transformation expert with experience in many projects, operating in the intersection of business strategy and AI technologies to drive impactful results.

• The blueprint: business strategy should drive the AI transformation.

Intro

Most AI transformation stories start with a tool. This one didn't. A pan-European real estate developer and operator, managing office and residential portfolios across Germany, Poland and Romania, had grown its physical footprint faster than its tenant operations model. Roughly 2,000 tenants generated €126 million a year, and the entire post-occupancy lifecycle, rent collection, utility billing, renewals, maintenance, compliance, ran on spreadsheets, email, monday.com and institutional memory.

The company didn't ask which AI agent to buy. It asked what tenant operations should look like if redesigned today, with modern data architecture and autonomous agents available from the start. That question, not the technology, is what makes this case worth studying. The sequence, strategy first, workflow second, data third, technology last, is the same sequence that separates AI transformation from AI automation. This post walks through how that sequence played out, what the agentic operating model actually did, and what the economics looked like when modeled conservatively.

What Was the Actual Problem Before AI Entered the Picture?

The core issue wasn't individual employee performance. It was the absence of a coherent tenant operating system.

• Each local office had built its own workflow. One team used monday.com, another ran parallel Excel trackers.

• Critical information sat in personal inboxes rather than a shared system.

• Some processes depended entirely on an employee remembering to check something.

• There was no consistent end-to-end playbook across the group.

Approximately 10-15 employees spent most of their time checking whether payments arrived, reconciling systems, chasing vendors, updating spreadsheets and searching old emails for context. They were functioning as the integration layer between disconnected systems, not as relationship managers or operators.

What Did Fragmentation Actually Cost the Business?

It cost more than labor hours. Four categories of friction compounded.

• Revenue and cash-flow friction. Late collections, billing corrections, and repeated manual follow-up on outstanding balances.

• Contract and renewal risk. Manually tracked expiration dates meant renewals were approached inconsistently, sometimes too late to retain a valuable tenant.

• Service failures. Maintenance requests moved through disconnected channels, could be duplicated or forgotten, with tenants having little visibility into status.

• Compliance gaps. Insurance certificates and contractual obligations required manual date-tracking and manual tenant chasing.

Management couldn't answer basic portfolio questions in real time: which tenants were overdue, which renewals were approaching, which buildings had recurring problems. The company had data. It didn't have an operational picture.

Why Did the Transformation Start With Strategy Instead of Automation?

Because automating a broken workflow just makes the workflow break faster.

The first phase wasn't about tools. It was about identifying business leverage points: improving operational economics, protecting revenue through better collection and renewal discipline, improving tenant experience, and, critically, using tenant operations as competitive differentiation.

That last point reframed the whole project. Tenants don't judge a landlord only on the physical asset. They judge it on billing clarity, maintenance responsiveness, communication consistency and how renewals are handled. A landlord that makes those interactions easy builds a reputation as a superior long-term operating partner. Tenant operations stopped being an administrative cost center and became part of the customer proposition.

How Did the Team Map the Existing Workflow Before Touching Technology?

They mapped the actual process, not the documented one.

For each tenant journey, the team tracked the initiating event, the responsible employee, where information originated, which system stored it, every internal and external handoff, documents created, approvals required, and completion criteria.

This exposed a gap between the formal process and the real one. The formal process said renewals should start a set number of months before expiration. The actual process depended on someone noticing a date in a spreadsheet. The formal process said maintenance tickets close on completion. The actual process involved several back-and-forth emails between tenant, property manager, technician and an external contractor. Mapping surfaced exactly where the operation relied on human memory instead of system logic.

Why Was Fragmented Data a Bigger Problem Than Fragmented Process?

Because an AI agent cannot act reliably on information it cannot trust.

Tenant records were duplicated across spreadsheets, monday.com, email threads, and local property-management practices. Different offices stored different fields for the same tenant. No one owned specific data elements with authority.

An agent cannot decide whether to send a collection notice if it can't determine which contract version is current, what's actually owed, whether payment already arrived, or whether a dispute is active. Agentic AI cannot be layered safely on top of fragmented operational data. This is the step most transformations skip, and it's the one that determines whether everything built afterward actually works.

The fix was a canonical tenant model: Property, Unit/Space, Tenant, Lease, Charges, Payments, Utilities, Documents, Service Requests, Compliance, Renewals and Communications, all interconnected inside one authoritative environment. The company chose consolidation over federation. Legacy spreadsheets and local monday.com processes didn't get connected to the new system. They were retired. Data migrated. Workflow migrated. Operating model migrated.

What Changed When the Company Reimagined the Process From First Principles?

The team asked a deliberately uncomfortable question: if we designed tenant operations today, with autonomous agents available from day one, would it look anything like this? The answer was no.

That question challenged assumptions embedded in nearly every part of the workflow. Why should an employee scan a spreadsheet to discover overdue rent? Why should a property manager need to remember a lease expires in six months? Why should a tenant have to email asking for a maintenance status update? Why should management learn about recurring building problems through anecdotes instead of data patterns?

The objective shifted from automating employee tasks to redesigning the operating model around five principles:

• One operational truth. All tenant operations reference the same tenant, lease, property and transaction data.

• Event-driven, not memory-driven. A lease approaching renewal starts the renewal workflow automatically. A payment going overdue starts the collection workflow. Nobody has to remember to check.

• Automation first, human exceptions second. Routine cases move without continuous human coordination. Humans engage where judgment, empathy or risk justify it.

• Proactive, not reactive. The system flags issues before the tenant has to raise them.

• Intelligence that compounds. Operational outcomes become new information that improves future decisions.

What Do the Actual Agents Do?

Six functional agents replaced manual coordination across the tenant lifecycle.

• Collections agent. Monitors obligations and payment status continuously, initiates communication sequences, personalizes messaging by tenant context, escalates by predefined rules, and surfaces disputes to a human. Employees no longer inspect every account; they manage exceptions.

• Lease and renewal agent. Monitors lease milestones, assembles the existing lease and amendments, identifies contractual options, summarizes tenant history, and flags high-value or unusual renewals for human review. The relationship manager focuses on negotiation, not administrative prep.

• Utilities agent. Ingests consumption and charge data, reconciles it, applies allocation rules, flags anomalies, and generates tenant-level charges. Deterministic calculations stay deterministic. AI is used for interpretation and exceptions, not arithmetic.

• Service and maintenance agent. Takes a tenant's natural-language description of a problem, identifies the property and unit, classifies urgency, creates and routes the work order, follows status, and escalates delays.

• Compliance agent. Continuously monitors insurance coverage, certificates, missing documentation and contractual requirements, and automates routine reminders.

• Tenant-service agent. A single intelligent entry point for tenants to ask about balances, request documents, report issues or raise a renewal conversation, without needing to know which internal team handles it.

One capability worth highlighting: pattern detection across the portfolio. If multiple tenants in the same building report similar HVAC problems, the system can recognize a shared building-level issue instead of processing ten isolated tickets. Similarly, a combination of recurring complaints, slowing payments, and an approaching lease expiration can trigger proactive human outreach before a tenant signals intent to leave. That's the shift from processing work faster to seeing patterns the old process obscured entirely.

How Was Human Work Redesigned, Not Just Reduced?

The project didn't treat headcount reduction as the goal. It treated role redesign as the goal.

In the old model, employees spent most of their time checking, chasing, copying, updating, routing, reconciling, reminding and searching. In the new model, their time concentrates on complex disputes, major renewals, sensitive service situations, negotiation, vendor performance management and unusual contractual issues.

As automation matured, the staffing requirement was expected to decline from 10-15 FTEs to approximately four over two to three years, with the remaining team doing meaningfully higher-value work. Fewer people, but a different job entirely.

Why Did the Company Choose to Buy a Platform Instead of Building Custom AI?

Because the company didn't need to become an AI software company to fix tenant operations.

The principle applied was straightforward: build differentiation only where differentiation is required, buy mature infrastructure everywhere else. The company had no large internal AI engineering function, so building a proprietary data architecture, agent orchestration layer and tenant-facing interface would have added complexity without adding advantage.

Yardi was selected as the operational core. Its commercial platform centralizes property and tenant data; its CommercialCafe and RentCafe environments give commercial and residential tenants a connected interface for payments, maintenance and communications tied directly to the underlying system. The more consequential piece was Yardi Virtuoso, a connected AI layer providing native agents, connectors, agent management, and a low/no-code environment for building additional agents. By 2026, Yardi was extending these capabilities into commercial leasing, maintenance and accounting workflows as well, which materially changed the buy-versus-build calculation.

What Did the Resulting Architecture Actually Look Like?

A closed loop, not a point solution.

• Operational core: Yardi as the system of record for tenant and property data.

• Data foundation: tenant, property, lease, payment, maintenance and compliance data standardized in one environment.

• Workflow layer: business events and rules trigger the right process automatically.

• Agentic layer: native agents handle or assist workflows, with configuration preferred over building separate applications when a standard agent doesn't exist.

• Experience layer: tenants interact through proper digital interfaces, employees stay inside the same operational environment rather than adopting a separate AI tool.

• Human-control layer: high-risk or judgment-intensive actions stay with employees.

The loop itself: a tenant or business event triggers the Yardi system of record, which applies workflow and business rules, which triggers an agent or automation, which produces an action or recommendation, which either executes automatically or routes to a human, with the outcome written back into Yardi. The system doesn't just generate an answer. It participates in the workflow and closes the loop.

Why Did Migration Matter as Much as the Platform Choice?

Because a bad process with dirty data inside a modern platform is still a bad process.

Selecting Yardi didn't fix the data problem by itself. The company had to inventory tenant records, identify duplicates, determine which record was authoritative, standardize fields, normalize property and lease structures, migrate current contracts and relevant payment history, and eliminate redundant spreadsheets. The objective wasn't loading data into a new system. It was creating a trusted operational model capable of supporting automation. Skip this step and the new platform just centralizes the old errors.

How Did the Company Decide What Agents Could Act On Autonomously?

By separating actions into risk tiers before deploying anything.

• Low-risk, repetitive activity (reminders, document requests, ticket creation, status updates, routine routing): high automation.

• Moderate-risk actions (certain billing exceptions, renewal preparation, vendor routing): AI prepares or recommends, with configurable approval.

• High-risk activity (contract disputes, eviction or legal escalation, material renegotiation, significant concessions): human control remains mandatory.

The design principle was economically useful autonomy with appropriate control, not maximum autonomy. This required making implicit operating knowledge explicit: when should a late-payment reminder escalate, who can authorize a special arrangement, which insurance failures represent actual risk. Agents need precision that experienced employees previously carried informally. Forcing that knowledge into explicit policy improved operational discipline on its own, independent of the automation that followed.

What Did the Economics Actually Look Like?

The base-case estimate treated the friction as 1.25% of tenant revenue: €126M x 1.25% = €1.575M, rounded to approximately €1.6M in annual economic friction. This covered manual work, errors and rework, delayed collections, service failures, missed renewals and compliance administration, not a claim that 1.25% of rent was permanently lost.

Recovery was modeled as a ramp, not an immediate jump: 25% of friction recovered in Year 1, 55% in Year 2, 75% from Year 3 onward. That put mature-state recovery at approximately €1.2M annually, with the remaining 25% intentionally left unrecovered. Some exceptions always require human handling, and chasing the last fraction of inefficiency usually costs more than it returns.

Using conservative implementation assumptions, an initial transformation cost of €600K, incremental annual platform and operating cost of €180K, and a 10% discount rate, the five-year case worked out to a present value of gross benefits around €3.50M, present value of costs around €1.28M, net NPV of approximately €2.22M, payback of roughly 1.6 years, and undiscounted five-year net value of approximately €3.30M. The business case didn't require aggressive assumptions about AI productivity to justify itself.

What Value Wasn't Even Counted in That NPV?

Several benefits were deliberately excluded because they're harder to attribute directly, but they matter.

• Tenant retention. On €126M of annual revenue, even small retention improvements from better service can exceed the direct administrative savings.

• Reputation and occupancy. A landlord known for responsive, transparent service has a stronger customer proposition in a competitive market.

• Better renewals. Proactive intelligence gives management more lead time to retain or renegotiate with valuable tenants.

• Portfolio intelligence. Structured data across thousands of tenant interactions becomes a strategic asset in its own right.

• Scalability. The company can grow its tenant base without proportional headcount growth.

• Option value. Once tenant data and workflows are structured, new services become far easier to introduce.

What Risks Did the Company Have to Manage Through Implementation?

Five risks were named explicitly rather than assumed away.

• Migration failure. Incorrectly migrated legacy records would just centralize existing errors in a new system.

• Local resistance. Country teams that built their own workflows could resist replacing them.

• Over-automation. Agents acting without properly defined boundaries could introduce new operational or customer risk.

• Poor adoption. Employees might keep shadow spreadsheets if they didn't trust the new system.

• Vendor dependency. Centralizing the workflow inside one platform increases platform dependence. The response was to govern that dependency explicitly, not to avoid centralization.

Was This Actually a Software Implementation, or Something Bigger?

It would be easy to call this a Yardi rollout. That description misses most of what changed.

The technology was one component among many decisions: what tenant service should achieve, how value was created, which activities should disappear versus get automated, which decisions still required people, where authoritative data should live, which policies needed to become explicit, and how customer experience should be measured. Yardi became the enabling platform. It was not the transformation itself.

Closing: What This Case Actually Demonstrates

The before-state was a fragmented tenant-management function where employees manually coordinated thousands of recurring activities through spreadsheets, email and individual memory. Problems became visible only when someone happened to notice them.

The after-state is a centralized, event-driven operating model built on one authoritative tenant record, where software continuously monitors operating state, events trigger workflows, AI handles repetitive coordination, exceptions surface to humans, and management sees the portfolio through real-time signals instead of anecdotes.

There's a meaningful difference between adding AI to an organization and redesigning an organization around what AI now makes possible. The first approach produces assistants and isolated automation. The second changes how the business actually operates. This transformation didn't start by asking how to send reminders faster. It started by asking why employees should be sending most of those reminders at all. That question is what took it from workflow analysis to data redesign, from data redesign to an event-driven model, and from that model to an integrated technology architecture. That sequence, not the software vendor, is the actual transformation.

FAQ

What was the core problem in this tenant operations transformation?

The company lacked a coherent tenant operating system. Each office ran its own workflow across spreadsheets, monday.com and email, so employees spent most of their time acting as a manual integration layer between disconnected systems rather than managing tenant relationships.

Why did the company fix its data model before deploying any AI agents?

Because agents cannot act reliably on fragmented data. An agent can't decide whether to send a collection notice if it can't determine the current contract, the amount owed, or whether payment already arrived. The company consolidated tenant, lease and payment data into one authoritative model before automating anything.

Why was Yardi chosen instead of a custom-built AI platform?

The company applied a buy-before-build principle: build differentiation only where it's actually required. Yardi already centralized property and tenant data and, through its Virtuoso layer, provided native agents and a configuration environment, removing the need to build a proprietary AI stack.

What was the modeled financial outcome of the transformation?

Annual economic friction was estimated at approximately €1.6M, or 1.25% of the €126M tenant revenue base. At maturity, roughly €1.2M of that was expected to be recovered annually, with a five-year net NPV of approximately €2.22M and a payback period of about 1.6 years.

How does this case study relate to Dan's 12-Week Breakthrough coaching work?

The same sequencing discipline, strategy before workflow, workflow before data, data before technology, is what separates account executives who use AI as a productivity add-on from those who restructure their entire pipeline approach around it. The 12-Week Breakthrough applies that same execution logic to individual sales performance rather than enterprise operations.

Is this level of AI transformation only relevant to large enterprises like the one in this case?

No. The principles, mapping the actual workflow, fixing the data foundation before automating, defining risk tiers for autonomy, apply at any scale. Individual AEs going through the 12-Week Breakthrough system use the same logic: don't automate a broken personal process, fix the underlying structure first.

What's the practical first step for someone trying to apply this thinking to their own role or business?

Map the actual process, not the documented one, the same way this case study did. Most people find the gap between what they think they do and what they actually do is where the real inefficiency lives, and it's the same diagnostic starting point used in 12-Week Breakthrough coaching engagements.