Plumbing First. AI Follows.

Unwired Logic - 2026 edition

For owners and operators who have read the vendor AI guides, tried a few prompts, and are wondering why the result still feels like a toy.

Why this guide reads differently

There is a genre of AI guide for storage operators now. You have probably read one. It explains what a large language model is, lists the places AI can help (lead response, summaries, reporting, marketing copy), warns you about hallucinations, teaches you to write a better prompt, and closes with a demo request.

None of that is wrong. It's the last five percent of the job, presented as the whole job.

We implement technology for self-storage operators - property management systems, ticketing, phone systems, payments, reporting - across the UK, Europe, Australia and Asia. Our observation from that work is simple. Operators do not get stuck on AI because they prompt badly. They get stuck because the AI can't see their business. It can see one database, usually the PMS, and the questions that actually run a storage company live across four or five systems that have never been connected.

So this guide is about the plumbing. The AI part comes last, on purpose, because that is the order it works in.

The question nobody puts on page one

Before you ask "what can AI do for my business," ask "what can the AI see."

An AI assistant is only as useful as the data it can read at the moment you ask the question. If it can read your PMS, it can tell you occupancy, arrears, move-ins, rate history. Useful. But try these:

Which enquiries did we lose last week? The missed call is in your phone system. The unanswered email is in a manager's inbox. The web form that never got a reply is in a form tool. None of them reached the PMS, because a lost lead never becomes a tenant. The most expensive leak in a storage business is invisible to a PMS-connected AI by definition.

Which overdue tenants already paid this morning? That needs the payment processor next to the PMS, or someone chases a customer who settled an hour ago.

Does our month-end actually reconcile? PMS, payments and accounting disagree more often than most operators want to know, and no single one of them can tell you.

Which tenants are about to leave? The signal shows up in support tickets and call logs weeks before it shows up as a move-out notice.

Every one of those is a cross-system question. A prompt doesn't fix that. Plumbing does.

Your business lives in five systems

Count them. A multi-site storage operator runs on a PMS (units, tenants, rates, balances), a customer communication system (email, chat, WhatsApp, web forms - whatever handles the inbound), a phone system, a payment processor, and accounting. Add an ad platform if you spend on marketing. That is the real shape of the business.

Most operators have never drawn that picture. They think of the PMS as "the system" and everything else as around it. The PMS vendors are happy to agree, which is why every PMS now ships an AI connector that reads the PMS and nothing else.

The value of AI in a storage business is proportional to how many of those systems it can see at once. One system gives you a smarter dashboard. All of them give you a business that can answer its own questions.

The position we hold on CRM

While you are drawing the picture, look hard at the box labelled "customer communication."

Our position, stated out loud for years: a B2B CRM is the wrong platform for self-storage. Storage is not a sales business. It is an inbound-leads-and-subscription business. The sales cycle is hours to a couple of days, conversational, and arrives on whatever channel the customer picked. B2B CRMs are built for opportunities and pipelines. They need integration work before they can even see a WhatsApp message.

An omnichannel ticketing system fits the actual unit of work. Phone, email, chat, WhatsApp and web land in one queue with one history per customer. Respond fast, convert, keep them paying. Every enquiry is a record whether or not it ever becomes a tenant - which is exactly what makes the lost-lead question answerable.

This matters for AI more than it matters for anything else. An AI reading a ticketing system can see every conversation your business has ever had, on every channel, including the ones you lost. An AI reading a CRM sees the opportunities someone remembered to log.

AI reads data. It does not clean it.

The least glamorous section, and the one we would keep if we had to cut everything else.

Point an AI at a PMS where unit types are inconsistent across sites, old tenants were never properly moved out, discounts are recorded three different ways and half the phone numbers are dead. You'll get confident, well-written answers that are wrong. Polished garbage, and polished garbage gets acted on.

Before connecting anything, answer four questions. Are unit types and pricing recorded consistently across every site? Do move-outs, transfers and write-offs actually get processed in the system, or do they live in someone's head? Does your PMS balance reconcile against what your payment processor and your accountant say? Is there one contact record per customer, or five?

If the answers embarrass you, fix that first. It is cheaper to clean data before AI reads it than to unwind decisions made on bad output. No AI tool, however good, skips this step for you.

The architecture, in the order it gets built

Think of it as a stack. The order is the point.

Systems of record at the bottom. PMS, ticketing, phone, payments, accounting. Each one does its job, each one holds its own truth. Your first investment is making sure each is set up properly and holds clean data, because everything above it inherits whatever is here.

The connection layer next. This is what most operators are missing. API keys and connectors that let something outside each system read it. Two rules that are not negotiable: access is read-only, and the keys are created inside your own systems, by you, revocable by you without asking anyone. AI should read your data. It should never be in a position to edit a record, move a tenant, message a customer or change a price.

A data layer when you outgrow live lookups. For one site on one modern system, connectors are enough - the AI reads each system live when you ask. For multi-site operators, or anyone who wants dashboards, investor reporting and a month-end that writes itself, the next step is a central data layer. A reporting tool or a proper warehouse. Every system feeds it on a schedule, and from then on there is one place that knows the whole business. We have said for years that centralised reporting is the most underrated investment in storage. AI is the reason it is finally obvious.

AI on top. Only now. And notice what has happened: by the time you get here, the AI is the cheapest, most replaceable part of the stack. Any capable model can read a clean data layer through a read-only connector. You are not locked to whichever assistant your PMS vendor bundled. You can switch models next year without touching anything underneath.

Build the plumbing and any AI works. Pick the AI first and you get the plumbing your vendor happened to build, which sees your vendor's database and stops.

What vendor AI is for, and where it stops

The PMS connector your vendor shipped isn't useless. Use it. Ask it the overdue list. Ask it which unit types have been vacant longest. Save the questions you ask most. That is a reasonable first rung, and for a single-site operator on one modern system it may be all you need for a year.

Be clear about where it stops, though, because the vendor's guide won't say it. A PMS AI can't see a missed call. It can't see a payment that landed in the processor but not yet in the PMS. It can't see a support ticket. It can't tell you your marketing spend produced a move-in. It is a very good window onto one room.

The operators who get real return from AI treated the vendor connector as a starting point and built the connection layer around it.

The ladder, and why most operators stop on rung one

Most operators we talk to have connected an AI to their PMS, asked it some questions, and think they are done. That is rung one of five.

Rung 1 - Ask questions. Connect the assistant to the PMS and ask things. "Who is more than 30 days overdue?" Better than exporting a spreadsheet. But if the answer is a number you could have read off a dashboard, you are underusing the tool.

Rung 2 - Save what works. The tenth time you type the same collections question, save it. Now the analysis is consistent - same criteria, same format, whoever runs it.

Rung 3 - Put it on a schedule. This is the rung that separates a toy from a tool. A saved process that runs every Friday morning works whether or not anyone remembered to ask. Most operators stall permanently between rungs 2 and 3.

Rung 4 - Live visibility. Scheduled outputs become standing briefings: a daily three-things-need-your-attention summary, a month-end review that writes itself.

Rung 5 - Cross-system processes. Processes that read the PMS, ticketing, phone, payments and accounting together. No single vendor's connector reaches this rung. It is the whole reason the plumbing exists.

The ladder doesn't skip. If you are on rung 1, the next move is rung 2, not rung 5. But rung 5 is where the return is, and you cannot climb to it on a single-system connector.

What "AI follows" looks like once the plumbing exists

Once the AI can see across systems, the useful work stops being questions and starts being scheduled processes. Not chat. Things that run Friday at seven whether or not anyone remembered to ask. These are the ones we see deliver most for multi-site operators.

On the money side: a weekly collections pack that groups overdues by age, subtracts everyone who paid since the last run, drafts the reminders in your tone and flags the tenants with an open complaint so nobody sends a demand letter into an unresolved ticket. A reconciliation watchdog that stays silent when PMS, payments and accounting agree and pings you only when they don't. A pricing radar that names which unit types to raise and which to promote, with competitor street rates alongside.

On customers and leads: a dropped-lead alert that lists every missed call and unanswered enquiry across phone, email and web, daily. A churn watch that ranks at-risk tenants by signal strength and revenue at stake, retention outreach drafted for review. A win-back scan of recent move-outs worth a message, with the message drafted.

On visibility: a daily briefing of the three things across all sites that need your attention today. A month-end review across every connected system, written for your partners or your lender. A governance audit of who changed what in your systems, with unusual activity flagged.

Two rules make these safe. Every process drafts, never sends - a human reviews anything customer-facing before it goes out. And every output states its sources ("based on 214 records from your PMS and 38 payment events") so you verify rather than trust.

Here is what one looks like, so you can judge the format rather than imagine it. Names and numbers are invented.

Weekly collections pack - Friday 07:00
Sources: 46 overdue accounts from your PMS, cross-checked against 312 payment events from your payment processor (last 14 days).

Paid since last run - no action: 9 accounts settled this week. Removed from the chase list. Two of them would have been contacted under your old process.

1-14 days overdue (22 accounts): standard reminder drafted for each, in your house tone. One flag: unit B-114 has a failed card on file - reminder includes the update-card link instead of a generic nudge.

15-30 days (11 accounts): firmer letter drafted, late fee stated per your policy. Three of these tenants have an open support ticket - drafts reference the ticket so you do not send a demand letter into an unresolved complaint.

31+ days (4 accounts): these need a decision, not a letter. Listed by balance at risk, with lien-process eligibility dates per site policy. Recommend a call on the largest two.

Nothing sent. All drafts are queued for review. Approve, edit, or discard.

Notice what makes this different from a report. It subtracts the people who already paid. It reads a second system before writing to a customer. It ends in decisions rather than numbers. None of that is possible on a single-system connector. All of it is routine on a connected stack.

The "human touch" objection

Someone on your team will raise it. Customers want a person. AI is cold. Storage is a relationship business.

We only half buy it. Storage is a distress purchase - death, divorce, downsizing, displacement. Nobody wakes up wanting a unit. What most customers experience as good service is speed and reliability: the enquiry answered in minutes, the booking that works at 11pm, the billing issue fixed on the first contact. Every one of those is easier to deliver with connected systems than with a thin counter staff and good intentions.

Where a person genuinely changes the outcome is when they care and can make a decision on the spot. That is usually the owner, or a manager with real authority - not a script read by someone who can't bend it. In a mature, competitive market, the scripted version of the human touch is overrated. The owner version isn't. So put people first where they can actually decide something, and put AI on the overflow, the after-hours enquiries and the follow-up, so your people spend their time where it counts.

The same logic applies to hardware. Smart locks get pitched as the start of a remote-operations plan. Run the math first: per-door capex plus a per-door monthly subscription, against a benefit that is mostly convenience. In our experience operators install one building or one floor and stop, because the numbers stop working. The real remote-ops stack is boring - online booking that works end to end, one inbox for every channel, call handling with after-hours coverage, automated billing with a collections process behind it. Get those right and most facilities need far less on-site presence. Get them wrong and no amount of hardware saves you. Be suspicious of anyone who puts hardware at the start of the plan instead of the end.

On headcount, one prediction we will state confidently: AI collapses routine work faster than it collapses judgment work. The operator of 2028 needs fewer people doing data entry and payment chasing, and better people doing escalations and revenue decisions. Plan around that direction of travel, not around the org chart you inherited.

Questions to put to any vendor, including us

Is access read-only? Who creates and holds the keys? Is my data used to train models, on the specific plan being used? Where does my data sit, and is there a standing copy held by a third party? Who approves output before anything customer-facing, financial or legal goes out?

The acceptable answers are known. Read-only. You hold the keys. No training on business plans, confirmed in writing. Read at query time or stored in your own accounts, never the vendor's. A human at your company, always. Anything else is a red flag, and a vendor who stumbles on these is telling you something about their plumbing.

Where to start

Draw the five-system picture for your business. Name each system and write down whether it has an API and whether anyone has ever used it. Most operators finish this exercise surprised.

Fix the inbound. If customer communication is spread across a shared mailbox, a chat widget, personal WhatsApps and a CRM nobody updates, consolidate it into one ticketing queue before you do anything with AI. This is the single highest-return move in the stack and it has nothing to do with AI.

Run the data audit. Four questions, honest answers. Clean what embarrasses you.

Create read-only keys in each system, yourself. Connect the PMS first, then whichever system holds your lost leads - usually phone or ticketing.

Build the data layer when you cross two sites or two systems, whichever comes first.

Then, and only then, put AI on top. Start with the collections pack or the dropped-lead alert, run it for a month with a human checking every output, and decide with evidence what to scale.

If you run one site on one modern system, you can do all of this yourself and you should. If you run multiple sites across multiple systems, the work above the connection layer is systems integration, not prompt writing, and the cost of doing it badly - acting on wrong numbers - exceeds the cost of doing it once, properly.

Appendix: score yourself

One page. Answer honestly, then hand it to your ops manager and compare answers.

Where are you on the ladder?

Plumbing - one point per honest yes

1. You can name every system your business runs on and whether each has an API.
2. Every inbound channel lands in one queue with one history per customer.
3. Read-only keys exist for each system, created by you, revocable by you.
4. Unit types and pricing are recorded consistently across all sites.
5. Move-outs, transfers and write-offs are processed in the system, not tracked in someone's head.
6. PMS balances reconcile against the payment processor and the accountant.

Leak check - one point per honest yes

1. You know how many enquiries you missed last week, across phone, email and web.
2. Nobody chases a tenant who has already paid.
3. Your month-end covers every site from one source, not stitched spreadsheets.

Reading your score. Ladder 0-1 with a plumbing score under 4: the roadmap is the "Where to start" section, and none of it involves AI yet. Ladder 2 with plumbing 4-6: your next move is a schedule, not a new tool. Any ladder position with a leak-check score under 2: your most expensive problems are in the systems your PMS cannot see, and that is the conversation worth having - with your team or with us.

About Unwired Logic

Unwired Logic implements and integrates technology for self-storage operators: property management systems, omnichannel ticketing, phone systems, payments, reporting, and the AI processes that run across them. We work with operators across the UK, Europe, Australia and Asia.

If you want a second pair of eyes on your stack before the AI conversation starts, book 30 minutes.

© 2026 Unwired Logic. General information, not advice on your specific systems. Verify against the exact tools in your stack before acting.