Welcome back to Exit & Equity, the email for serious self storage owners.
Today we're talking about the most frustrating thing in self-storage software: the data you're paying for but can't actually see.
Let’s go!
&
IN THE KNOW
Your property management software logs every inquiry that comes through your website. Every single one.
The timestamp. The unit size they asked about. Where they came from (Google, Facebook, referral). Whether they converted to a rental or disappeared.
All of this data exists. Your PMS captures it.
But when you log in and try to answer basic questions like:
Which marketing channel actually converts best?
What time of day do most inquiries come in?
Which unit sizes generate the most interest vs. which actually rent?
Do leads on weekends convert worse than weekday leads?
...your PMS gives you nothing.
Or worse, it gives you a generic "Lead Report" that shows a list of names with no analysis, no patterns, no insights.
The data is there. Your software just won't show it to you.
This isn't an accident. Most property management systems are built to handle transactions, thinks like charging rent, tracking leases, processing payments. They're very good at that.
But they're terrible at giving you operational intelligence. They collect thousands of data points per month that could tell you exactly where you're leaving money on the table, which managers are underperforming, which marketing spend is wasted, and which operational changes would have the highest ROI.
And then they bury that data six menus deep with no way to analyze it.
I got tired of this. So I started treating my PMS like a data engineer treats any system: as a source of raw data that needs to be extracted, cleaned, and analyzed outside the vendor's limitations.
Here's what's hiding in your PMS—and how to dig it out.
THE 6 HIDDEN GOLDMINES IN YOUR PMS
Your PMS tracks all of this data in the background. The question is: can you get to it?
For each goldmine, I'll show you what insight is hiding, where the data lives (even if your PMS won't report on it), and what decision you can make with it.

💎 LEAD SOURCE PERFORMANCE - Conversion vs Volume
What's hidden:
Most PMS systems show you "where leads came from" (Google Ads, Facebook, walk-in, referral). But they don't easily show you conversion rate by source or quality of tenant by source (length of stay, payment reliability).
⛏️ The insight you're missing:
Let's say Google Ads sends 40 leads/month, Facebook sends 30 leads/month.
Standard report says: "Google is winning, spend more there."
But when you extract the raw data:
Google converts at 15% (6 rentals)
Facebook converts at 35% (10 rentals)
Facebook is actually 2x better
Worse: When you track length of stay:
Facebook tenants stay 18 months average
Google tenants stay 9 months average
Facebook tenants have 2x the lifetime value
You should be spending MORE on Facebook, less on Google, but your PMS just shows "40 vs. 30 leads" and you're doing the opposite.
Where this data lives:
Lead source: Captured in PMS at inquiry stage (stored in leads database)
Conversion: Whether that lead ID later became a tenant (stored in tenant database)
Length of stay: Move-in date to move-out date (stored in tenant history)
The problem: These are three different reports/tables that your PMS doesn't connect for you.
How to extract it:
Export "All Leads" report for last 12 months (CSV)
Export "All Move-Ins" report for same period (CSV)
In Google Sheets: Use VLOOKUP to match lead ID to tenant ID
Calculate conversion rate by source
Add column for "Days as Tenant" for each converted lead
Pivot table: Source → Conversion % → Avg Length of Stay
What decision this enables:
Reallocate your marketing budget to channels that actually convert AND retain, not just the ones that generate the most noise.
Real example:
When I ran this analysis, I discovered my "Referral" leads had a 50% conversion rate and 22-month average stay vs. "Google Ads" at 12% conversion and 11-month stay.
I cut Google Ads spend by 60% and launched a referral incentive program ($50 rent credit for successful referral). My CAC dropped by 40% and tenant quality improved dramatically.
💎 UNIT VELOCITY What is actually getting rented
What's hidden:
You know your occupancy by unit size. But you don't know days-to-rent by unit size, how fast each size moves when vacant.
⛏️ The insight you're missing:
Let's say you're 90% occupied. Looks healthy, right?
But when you extract unit velocity:
5x5 units: Vacant average 4 days before renting
10x10 units: Vacant average 22 days
10x20 units: Vacant average 61 days
You have too many large units sitting empty while small units fly off the shelf.
This reveals "pricing friction":
If 10x10s rent in 2 days: Price is too low (you're leaving money on table)
If 10x10s take 45 days: Price is too high or units are in bad location
Where this data lives:
Vacancy start date: When unit becomes vacant (move-out date)
Rental date: When next tenant moves in (move-in date)
Unit size: Stored in unit master data
The problem: PMS shows occupancy % but not velocity (time vacant).
How to extract it:
Export move-out report (last 12 months)
Export move-in report (same period)
Match: For each vacancy, find the subsequent move-in for that unit number
Calculate: Days between move-out and move-in
Group by unit size
Calculate average, median, and range
The formula:
Unit Velocity = (Total Days Vacant) ÷ (Number of Rentals)
What decision this enables:
Unit mix optimization: Convert slow units to fast units (split large into small)
Pricing adjustment: If 10x10s sit 22 days but market rate is $150, try $140 to increase velocity
Acquisition strategy: When buying/building, favor unit sizes with fastest velocity in your market
Real example:
One of my facilities had twelve 10x20 units averaging 61 days vacant. I converted six of them into twelve 10x10 units (cost: $8K in construction).
Result: Those 10x10s now rent in 18 days average. Annual revenue increased $23K because I eliminated the slow-movers.
I know we are all here because we want to handle our own retirement path, but if you are looking for some help- Fisher Investments has a great guide to look at.
Will Your Retirement Income Last?
A successful retirement can depend on having a clear plan. Fisher Investments’ The Definitive Guide to Retirement Income can help you calculate your future costs and structure your portfolio to meet your needs. Get the insights you need to help build a durable income strategy for the long term.
💎 INQUIRY TIME CLUSTERING - When are your customers booking
What's hidden:
Every inquiry in your PMS has a timestamp. But your PMS doesn't aggregate this to show you peak inquiry hours or day-of-week patterns.
⛏️ The insight you're missing:
When you extract the raw timestamps:
43% of inquiries come in 6-9 PM weekdays
28% come in Saturday morning (9 AM - 12 PM)
Only 15% come in during "business hours" (9 AM - 5 PM weekdays)
Your office is closed when most of your leads come in.
Or your manager is at the facility but too busy with other tasks to respond quickly.
Where this data lives:
Inquiry timestamp: Captured in leads table (usually exact date/time)
The problem: PMS gives you a list of inquiries but no time-based analysis.
How to extract it:
Export leads report with timestamps (CSV)
In Google Sheets: Create column extracting hour from timestamp (=HOUR(A2))
Create column extracting day of week (=TEXT(A2,"dddd"))
Pivot table: Hour of Day → Count of Leads
Another pivot: Day of Week → Count of Leads
Create simple bar charts showing distribution
What decision this enables:
Adjust staffing: Have manager available 6-9 PM or use answering service
Set up auto-responder for after-hours inquiries: "Thanks for reaching out at [time]. We'll respond first thing tomorrow morning. In the meantime, here's our pricing..."
Know when to check for new leads most frequently
Real example:
I discovered 47% of my leads came in after 5 PM. I hired a part-time manager for evening shifts (4-8 PM, four days/week).
Response time dropped from 8 hours to 45 minutes. Conversion improved 23% because we were catching leads while they were hot instead of the next morning after they'd called three competitors.
💎 SEASONAL PATTERNS - Your own uniqueness
What's hidden:
You know storage is "seasonal" (summer busy, winter slow). But you don't know your specific facility's pattern or how pronounced it is.
⛏️ The insight you're missing:
When you extract move-in/move-out history by month:
May-August: Average 23 move-ins/month, 9 move-outs/month (net +14)
November-February: Average 8 move-ins/month, 12 move-outs/month (net -4)
This tells you:
Raise rates in March (before summer rush when demand spikes)
Avoid rate increases in September (heading into slow season)
Staff up April-May (high move-in volume)
Reduce hours November-January (low activity, save labor costs)
Time capital projects for November-February (low disruption to operations)
Where this data lives:
Move-in dates: Aggregated by month
Move-out dates: Aggregated by month
The problem: PMS doesn't chart year-over-year patterns or net movement velocity.
How to extract it:
Export 2-3 years of move-ins and move-outs
Create spreadsheet: Month → Move-Ins → Move-Outs → Net Change
Chart it: Line graph showing pattern over 24-36 months
Calculate average for each month across years
What decision this enables:
Pricing strategy: Raise rates before busy season, hold or reduce during slow
Staffing: Hire seasonal help for summer, reduce winter hours
Marketing: Ramp ad spend in March-April (catch early movers), reduce in fall
Capital projects: Schedule roof replacement in January, not June
💎 TENANT COHORT ANALYSIS - Who is staying longer when
What's hidden:
Do tenants who move in during peak season stay longer or shorter than off-season renters? Your PMS doesn't tell you.
⛏️ The insight you're missing:
When you analyze by move-in month cohort:
Tenants who move in May-August: Average 11 months stay
Tenants who move in November-February: Average 19 months stay
Off-season tenants are "stickier" (better lifetime value).
This might mean:
Peak-season tenants are transient (students, temporary moves, house sales)
Off-season tenants are deliberate (downsizing, business inventory, long-term storage)
You should focus MORE marketing in off-season, not less (better LTV per acquisition)
Where this data lives:
Move-in month: When they started
Move-out month: When they left (or "current" if still active)
Length of stay: Calculated from above
The problem: PMS shows individual records but no cohort comparison.
How to extract it:
Export all tenants (current + historical) with move-in and move-out dates
Calculate length of stay (in months)
Group by move-in month
Calculate average length of stay for each month's cohort
Compare: Are summer cohorts shorter-term than winter?
What decision this enables:
Marketing focus: If off-season tenants have 2x LTV, spend more acquiring them
Pricing: You might charge HIGHER rates in off-season (better tenants, less price sensitive)
Tenant screening: Understand seasonal risk (summer = more transient, adjust approach)
Real example:
I assumed summer tenants stayed longer because "that's moving season and people downsizing stay long-term."
Data showed the opposite: Summer cohort averaged 9.8 months, January cohort averaged 18.4 months.
I shifted 40% of my annual marketing budget to November-January (previously considered "dead season"). Acquired fewer tenants but with nearly 2x the LTV. Overall revenue increased because tenant quality improved.

WHY YOUR PMS WON'T SHOW YOU THIS (THE VENDOR PROBLEM)
The question most operators ask after realizing this data exists is: "Why doesn't my software just show me this?"
The answer lies in how property management systems are built.
They're Built for Transactions, Not Intelligence
Your PMS was designed as an "Online Transactional Processing" (OLTP) system. Its primary mission: maintain transaction integrity.
When a tenant pays $100, the system must ensure:
Balance is updated correctly
Unit stays rented
Gate remains accessible
Payment is logged
To do this efficiently for thousands of facilities simultaneously, the software is optimized for "current state" data—the right here, right now.
Analytical queries—like "Show me average stay length of tenants who moved in on Tuesdays"—require scanning millions of historical records. This is computationally expensive.
If a PMS vendor allowed every user to run complex analytical queries in real-time, the entire system would slow to a crawl, and the transactional integrity (taking payments) would be compromised.
The "Good Enough" Reporting Standard
There's also a vendor incentive problem.
PMS companies are evaluated on their ability to handle day-to-day operations. As long as the "Management Summary" provides enough information for a bank audit or tax return, the vendor has met the standard.
Providing deep, data-driven insights requires a separate architecture—often called "OLAP" (Online Analytical Processing)—which is expensive to build and maintain.
Rather than building these sophisticated tools, vendors often:
Provide "Business Intelligence" as a separate, premium module (extra $$$)
Rely on third-party marketplace partners to fill the gap
Just don't build it at all
This leaves the independent operator in a "data hostage" situation: The data is yours, generated by your business, but the vendor has made it nearly impossible to access without paying more or having a computer science degree.
The Complexity Filter
There's also a psychological element.
Software vendors want their products to feel "easy." A dashboard with 50 complex analytical metrics is intimidating to a new manager.
So the "default" reports are simplified to the point of being operationally shallow.
The gold is hidden not necessarily out of malice, but because the vendor has decided most operators don't want to see the complexity of their own data.
They're wrong. You do want to see it. You just need to extract it yourself.
&
MAKE IT MODERN
HOW DATA ENGINEERS "SOURCE" DATA (AND HOW YOU CAN TOO)
As an operator with a data engineering background, the most important lesson I've learned is this:
You don't need to wait for a vendor to "build" a report. You can "source" the data yourself.
In the tech world, we call this "ETL"—Extract, Transform, and Load.
For the self-storage operator, this is the process of getting the "shovel" and digging into your PMS.
Here's the 4-step process:
STEP 1: THE "BACKDOOR" EXPORT (Extraction)
The primary tool: CSV Export
Almost every report in SiteLink, storEDGE, and Tenant Inc has an "Export to Excel" or "CSV" button.
The secret: Ignore the "Summarized" reports. Look for the "Detailed" or "History" versions.
Examples:
In storEDGE:
The "Move-Ins/Move-Outs/Transfers" report in CSV format contains columns that don't exist in the PDF version: Business Name, Amenities, Transfer Unit Rate.
In SiteLink:
The "Marketing Roll" is a goldmine of longitudinal data that can only be properly analyzed once exported.
In Tenant Inc:
The "Audit Log" has manager override data that never appears in summary reports.
What to export this week:
All Leads (last 12 months)
All Move-Ins (last 12 months)
All Move-Outs (last 12 months)
Current Rent Roll with Standard Rates
These four exports will unlock 4 of the 5 goldmines.
STEP 2: THE "MIRRORING" TECHNIQUE (Transformation)
Once you've exported raw data, you need a "Staging Area."
For most independent operators, this should be a Master Google Sheet or Excel workbook.
You're not just looking at the data—you're "mirroring" it outside the PMS so you can manipulate it without breaking the system of record.
The transformation process involves "cleaning" the data:
Date formatting:
Ensure all dates are in consistent format (MM/DD/YYYY or YYYY-MM-DD)
Source standardization:
Your PMS might have "Google," "Google.com," and "Google Search" as three different sources. Merge these into one "Google Organic" category.
Remove blanks:
Filter out any rows missing critical data (no phone, no date, no unit size)
Create calculated columns:
Length of Stay = Move-Out Date - Move-In Date
Discount % = (Standard Rate - Actual Rate) ÷ Standard Rate
Days Vacant = Next Move-In Date - Previous Move-Out Date
This is tedious but crucial. Garbage in = garbage out. Clean data = reliable insights.
STEP 3: THE "PIVOT" INSIGHT (Insights)
This is where the magic happens.
The Pivot Table is the single most powerful tool for an operator.
It allows you to "re-slice" your data in ways the PMS vendor never imagined.
To find Unit Velocity:
Pivot by "Unit Type" and "Average of Days Vacant"
To find the January Effect:
Pivot by "Move-In Month" and "Average Length of Stay"
To find Manager Overrides:
Pivot by "Manager Name" and "Sum of Discounts Given" or "Average Discount %"
To find Lead Source Performance:
Pivot by "Lead Source" and calculate "Conversion Rate" (Count of Converted ÷ Count of Total)
By using a pivot table, you're essentially building your own "Analytical Database" on top of the transactional mess provided by your vendor.
You're no longer asking the software for a report. You're telling the data to give you an answer.
STEP 4: THE "API" HORIZON (Automation)
For operators with more than 5 facilities, manual CSV exports become a burden.
This is where APIs (Application Programming Interfaces) come into play.
An API is a "digital handshake" that allows your spreadsheet to talk directly to your PMS.
Systems with good API access:
Storeganise (API-first design)
Tenant Inc (robust API)
6Storage (growing API capabilities)
SiteLink (legacy but functional API)
What you can automate:
Daily revenue pull → Auto-logs to Google Sheet
Weekly occupancy snapshot → Feeds Monday.com dashboard
New leads → Auto-creates tasks in CRM
Delinquency alerts → Posts to Slack when tenant hits 30/60/90 days
If you find yourself exporting the same CSV every Monday morning, it's time to look at API automation.
Tools like Make.com or Zapier can connect your PMS API to Google Sheets, Monday.com, or Slack with no coding required.

THE BOTTOM LINE
Your property management software is a gold mine. The vendor just buried the gold six menus deep and didn't give you a shovel.
The six goldmines are real:
Lead source performance (which channels actually convert and retain)
Unit velocity (what rents fast vs. what sits vacant costing you money)
Discount penetration (which managers are giving away margin)
Inquiry time clustering (when your customers actually want to rent)
Seasonal patterns (your facility's unique rhythm for pricing/staffing)
Tenant cohorts (which move-in months produce sticky, high-LTV tenants)
The process to extract them:
Export the detailed/history reports (CSV files)
Clean and transform in Google Sheets (standardize, calculate)
Analyze with pivot tables (re-slice the data your way)
Automate with APIs if managing 5+ facilities (Make.com, Zapier)
You don't need to be a data engineer. But you can borrow the process:
Stop waiting for your PMS vendor to build better reports. They've had a decade. They won't.
Treat your PMS as a source of raw material. Extract the data. Analyze it in tools designed for analysis. Make decisions based on what the data actually shows, not what your PMS chose to report.
Pick one goldmine. Extract the data this week. Spend 2-3 hours with a spreadsheet.
You'll find something that changes how you operate. Guaranteed.
The data is there. You've already paid for it. It's time to use it.
P.S. - Which goldmine are you going to dig into first? Reply with a number (1-6) and I'll send you the exact step-by-step extraction process for that specific analysis.
&
BEFORE YOU GO
Links I found interesting this week
&
FROM THE STOICS
No person has the power to have everything they want, but it is in their power not to want what they don't have, and to cheerfully put to good use what they do have.
— Seneca

