Multifamily Acquisition Pipeline: From Broker Email to Asset Handover

Andrew Day·

Acquisition teams are rarely short of deals. They are short of time to prepare them, and the reason is unglamorous: the pipeline starts in an inbox.

Broker notes, teasers, forwarded threads, a rent roll as a PDF attachment, the same asset arriving from three intermediaries with different numbers attached. Very little of it is structured. A good share of it is duplicated. Before anyone can form a view on a deal, somebody has to turn all of that into something comparable.

What is an acquisition pipeline, in practice?

In theory it is the set of opportunities under evaluation and their stage. In practice it is whatever state your inbox is in, plus a spreadsheet that someone updates.

That gap matters, because the work of getting from one to the other is where most acquisition capacity actually goes. A pipeline is only as good as the point at which deals enter it, and for most teams deals enter it by hand.

Who pays the normalisation tax?

Usually an analyst.

Identifying the asset, reconciling which of the three versions is current, lifting figures out of an attachment and putting them into a model is work that requires care and almost no judgment. It also scales linearly with deal flow, which means the busier the market, the more of your analytical capacity goes into data entry.

The cost is not only time. Duplication is where error enters a pipeline. The same asset assessed twice under slightly different assumptions, or a stale set of numbers carried forward because nobody noticed a newer version had arrived, are both failures of housekeeping rather than of analysis. Both change decisions.

What does it mean to start the pipeline where the deal arrives?

It means treating arrival as the first step of the pipeline rather than as the thing that happens before it. Three things happen automatically as each opportunity lands:

  • Extraction. The asset, unit count, asking terms and figures are pulled out of the inbound itself, whatever form it arrived in.
  • Duplicate resolution. The same asset from multiple intermediaries is recognised as one opportunity with several sources, not three competing records.
  • Scoring against your own criteria. Not a generic screener's view of a good deal, but the things your investment committee actually weights, applied consistently to every deal before anyone opens it.

The last point is the one most often conceded. Every deal screener encodes somebody's thesis. If it is not yours, the pipeline is being made consistent about the wrong things.

Who should chase the missing information?

Most deals arrive incomplete. A rent roll without unit detail. A T-12 missing a month. No service history at all.

What follows is a week of correspondence: an analyst emailing a broker for the basics, following up, and reconciling what comes back. It is necessary work and a poor use of an expensive person.

Workflows can carry it instead. Requests go out against a checklist you define, responses come back in, and each deal fills itself in, with the gaps visible rather than discovered late. The analyst's attention moves to the part that cannot be automated, which is deciding which deals deserve it.

Why don't the financials tell you whether income is durable?

Because a trailing twelve-month statement confirms that income existed. It cannot tell you whether that income survives under new ownership, and the financials are silent on the difference.

Two assets can present identically in a model: same NOI, same occupancy. One has stable resident sentiment, a maintenance backlog under control and renewals holding. The other has deteriorating sentiment, a backlog that has been growing for a year and renewals propped up by concessions. Same page in the model, materially different hold period. (We have written separately on underwriting a multifamily deal beyond the financials.)

The evidence that separates them is operational and it is unstructured: work orders, service history, response times, the texture of how the asset has actually been run. Historically it was left out of diligence for a practical reason rather than a philosophical one. Reading a year of that material on a deal timetable was not feasible for anyone. That constraint is what has changed.

A note on where the line sits. This is asset-level evidence about how a property has been operated. It is not resident-level assessment, it has no place in screening decisions about individual residents, and we do not build it for that.

What happens to diligence work at closing?

Usually it is abandoned.

The model goes into the fund file. The operating detail stays in somebody's notes. The team taking the asset over starts again from the rent roll, rebuilding an understanding that already existed three weeks earlier.

That is costly at precisely the wrong moment. Resident support requests double in the first month after an acquisition. More than 40% of inherited staff leave within ninety days. Properties brought onto the owner's own systems inside that window contribute to fund returns faster than those left as they were found. We set out that window in more detail in ensuring success of a property acquisition within the first 90 days.

The fix is continuity rather than a handover document. If the context assembled during diligence already sits on the platform the team will use to run the asset, nothing has to be transferred at all. The people taking over inherit what was learned, including the specific problems diligence identified.

How Travtus fits

Every step described here can be bought as a point solution. Deal-flow trackers exist. Document extraction exists. None of it connects, which means each addition is another integration, another set of credentials, and another place where your thesis is encoded by somebody else. That is the platform versus point solution question, and in acquisitions it shows up as continuity: a deal tool stops at closing, because closing is where its job ends.

Travtus is the Everyday(AI)™ platform for multifamily. Your own teams describe how a deal should arrive prepared, which signals to weight, what context to attach and what should follow it into the hands of the people who will run the asset, and they build it themselves, without an engineering programme and without replacing the systems already in place.

Yours to build, in a sentence.

Frequently asked questions

Can deal information be extracted from broker emails and attachments automatically?

Yes. Extraction runs on the inbound itself, so the asset, terms and figures are captured whatever form they arrived in. The same asset arriving from several intermediaries is resolved into one opportunity with multiple sources rather than several competing records.

How do you score deals against your own investment criteria rather than a vendor's?

By building the scoring logic yourself. A generic screener applies the criteria its vendor chose, which is why it produces consistency about the wrong things. On a platform, the people who own the thesis describe what should be weighted and the pipeline applies it to every deal before anyone opens it.

How is operational evidence used in diligence without straying into resident screening?

The evidence is asset-level: work orders, service history, response times and how the property has been run. It informs a view on whether income is durable. It is not used to assess individual residents and it plays no part in screening decisions.

Does the diligence work carry over after close?

That is the argument for doing it on a platform rather than in a deal tool. The context assembled during diligence stays available to the team that takes the asset on, so the first ninety days start from what was already learned rather than from the rent roll.

Want to see what a deal pipeline built to your own criteria looks like? Explore the Travtus platform and how it connects deal-side context to the teams who run the asset after close.

See the platform in action