I used to work in data before I got into storage. Not the glamorous side. The plumbing side.

We built data warehouses for companies that had the same problem. Marketing lived in one system, revenue in another, finance somewhere else. Nobody could see how any of it connected.

The answer was always the same: integration is not visibility.

A connection between two systems just means data can move. It doesn't mean you can see how your marketing spend affects your move-ins, or how your move-ins affect your revenue.

I watched enterprise companies spend millions on integrations and still answer basic questions in spreadsheets.

Self-storage operators are doing the same thing, just at 600 units instead of 600 employees. Your FMS has 22 integration partners. That is not the same as having a single, coherent picture of your business.

There are questions you should be able to answer about your own facility.

These are not complicated questions. They are the questions enterprises pay entire data teams to answer. And they are questions most self-storage operators cannot answer today, not because the data doesn't exist, but because nobody has connected it.

That's the part the vendor pitch skips.

Managing your cap table doesn’t have to be complex. Pulley simplifies equity management for Founders and CFOs with intuitive workflows, accurate, audit-ready reporting, and predictable pricing—so you can plan and scale without surprises. Onboard in days, not weeks, and rely on responsive, expert support every step of the way.  

From issuing grants to 409A valuations or ASC 718 reporting, Pulley gives you the clarity to manage equity, make decisions, and get back to work. Experience a platform built for business owners and finance teams: transparent, reliable, and designed to put your company first.

See Pulley in action

Your integration list is real. The connections are real. When a tenant moves in, your PMS fires a record. Your marketing platform tags a lead source. Your call center closes a ticket. Your rate tool logs the street rate at time of move-in.

Every system did its job. Every event got recorded. And if you asked any of those vendors whether their system talks to the others, they would say yes. They would show you the logo on the integration page.

What they would not show you is the query. Because there isn't one.

A connection between two systems means data can move. It does not mean data lands in a place where it can be joined, modeled, or queried across systems with a shared key. Your FMS knows the move-in date. Your marketing platform knows the lead source. Those two facts live in separate databases, under separate tenant identifiers, in separate vendor clouds that you do not control. The integration means they shook hands once. It does not mean they can answer a question together.

Here is the question they cannot answer together: Did the tenant who came in through Google Ads last March, in a 10x10 climate-controlled unit, receive a rate increase in month eight — and did they stay or leave?

That question requires four data points from at least three systems, joined on a common key, with a consistent date spine. That is a data warehouse problem. It is not an integration problem. And no amount of logos on a capabilities deck changes that.

In enterprise, this is a known problem with a known solution. When I was doing this work before storage, we built the connective layer. Companies would have their CRM talking to their ERP talking to their marketing stack, and none of it could answer a cross-functional question without a ticket to IT. So they hired data engineers to build a central model — one place where all the exports landed, got cleaned, got joined, and became queryable. That model is what let the business actually run on data instead of just collecting it.

The self-storage version of that problem is identical. The scale is smaller. The budget for solving it is smaller. But the gap between "we have integrations" and "we can answer questions" is exactly the same gap.

Most operators do not know this gap exists because their FMS is genuinely good at what it was designed to do. It handles transactions. Move-ins, move-outs, payments, delinquency, lien processing — all of that works. The PMS is not broken. It was just never designed for analysis. It logs the event. It does not model the sequence of events over time in a way that produces insight.

So operators pull reports. They export a CSV from their PMS. They export something from their marketing tool. They look at them side by side in Excel and try to draw conclusions. That is the current state of data analysis for most independent operators, and it works about as well as you'd expect — which is to say it produces a feeling of having looked at data, not an answer to the question.

The AI pitch is making this worse, not better. The current promise is that you will soon be able to ask Claude a question about your facility and get an instant answer. That is true, conditionally. Claude can query what it can see. If you point it at a structured, consolidated dataset with your tenant history, your rate changes, your lead sources, and your move-out reasons all joined together — it will surface patterns faster than any report your PMS can generate. That part of the pitch is real.

The part that is not real is the idea that AI skips the data infrastructure step. It does not. If your data lives in three separate vendor portals with no shared key and no export to a common location, there is nothing for it to work with. The AI problem and the integration problem are the same problem. You have to build the model first.

The operators who understand this are not waiting for their FMS vendor to solve it. They are building something simple: a master export routine that pulls four or five key tables from each system on a regular cadence and lands them in one place. Not a data warehouse in the AWS sense. A Google Sheet or an Airtable base that gets fed by scheduled exports. Unglamorous. Completely functional. Enough to answer the questions that matter.

Four exports cover most of what an independent operator actually needs:

A full tenant history with move-in date, move-out date, unit type, and starting rate. A rate change log with tenant ID, date, old rate, and new rate. A lead source table if your marketing integration passes that through. And a move-out reason table if your PMS captures it.

With those four tables joined on tenant ID, you can answer questions your FMS dashboard will never show you natively. Which cohorts churned after rate increases. Which lead sources produced your longest-staying tenants. Whether your climate-controlled units outperform standard on retention. These are lifecycle questions. The PMS was built for transaction questions. That is the distinction worth understanding.

Your integrations are not broken. The vendors are not lying to you. The pipes are real. The problem is that pipes without a destination are just pipes. The consolidated model is the destination. Build it, and the integrations finally have somewhere useful to send their data.

The four-export model from In The Know sounds straightforward until you actually sit down to do it. Your FMS gives you a tenant history file. Your marketing platform gives you a lead source export. Your rate tool gives you a change log.

None of them share a column name.
None of them use the same tenant identifier format.

And now you have four CSV files open in four Excel tabs and no clear path to the analysis you actually wanted.

This is where most people stop. The task is not technically hard. People stop because there is no obvious next step, and figuring out the joins feels like a software engineering problem that has nothing to do with running a storage facility.

It is not a software engineering problem. It is a spreadsheet problem, and you can hand it off to AI in about two minutes.

Paste that in, run the formulas it gives you, and inside an hour you have a joined dataset that your PMS will never produce natively.

What you can actually answer once the Master tab exists:
Which lead source produces tenants who stay the longest. Sort by Lead_Source, average the Length_Of_Stay_Days column. Three minutes. You will probably be surprised by what is at the top and what is at the bottom.

Whether your rate increases are driving move-outs. Add a column for months between Move_In_Date and Move_Out_Date. Filter to tenants who received a rate increase. Look at whether move-outs cluster around a specific month post-increase. If they do, you have a retention problem that your street rate strategy is creating. If they do not, you have more pricing room than you thought.

Which unit types retain tenants longest. Group by Unit_Type, average Length_Of_Stay_Days. If your climate-controlled units are turning faster than standard, something is wrong with how you are pricing or marketing them.
None of this requires a data engineer.

None of it requires a new software subscription. It requires four exports, one prompt, and a willingness to spend an afternoon building something your FMS vendor should have built for you five years ago.

The point is not that this is elegant. It is not. The point is that it works, and it answers questions that operators who are running on gut instinct and PMS dashboards cannot answer at all. The gap between those two operators compounds over time. The one with the joined dataset makes a retention decision in October based on cohort data from the last two years. The other one looks at occupancy, shrugs, and holds the rate.

Build the model. Ask it the question. Then decide.

No links this week, just one question: which two tools in your stack do you wish actually talked to each other?

I'm building a list and it will probably become a future issue. The more specific the better!

not "my FMS and marketing" but "Sitelink and Google Ads so I can see cost per move-in without exporting two reports."

Hit reply. Two sentences is enough.

If one does not know to which port one is sailing, no wind is favorable.

— Seneca