Self-storage CRM: a tenant is more than a contact.

Buyers use the phrase for two different products. One is a sales CRM: enquiries, follow-up tasks, pipeline stages, quotes, conversion. The other is the operational tenant record used once someone reserves or rents a unit, joining customer service to inventory, billing, collections, documents and the rental lifecycle.

Codemind Storage is the second kind. Tenant management is deep after the reservation and the move-in, and deliberately thin before it. Being explicit about which one you are buying stops an evaluator acquiring a roadmap by accident.

Account information, rentals, invoices, payments, notifications, activity and documents, in one workspace. Custom fields capture whatever a particular operation needs to hold. Verified email and mobile state tell staff how the customer can actually be reached, and a business tenant can be looked up against Companies House rather than typed in from memory.

Identity and proof-of-address documents are stored with controlled review. A nominated billing contact receives financial notices while operational notices about the unit continue to go to the account, which is the difference between an invoice reaching an accounts inbox and an invoice sitting unread in the mailbox of a site manager who has left.

• Person or company, contacts, custom fields and Companies House details for a business tenant.
• Every rental, past and present, across every site the reader is permitted to see.
• Invoices, allocations, payments, saved-card state, payment plans, write-offs, refunds and disputes.
• KYC documents with a review status, uploaded by staff or by the customer.
• Email, SMS and print history with per-recipient delivery status and consent state.
• Door credentials, grants and the access-event history belonging to that tenant.

Exactly, rather than loosely. In a general CRM a customer is associated with a product or a deal. In storage a unit has a physical position and an operational status, a rental controls occupancy over time, a reservation holds future inventory, and a transfer changes the occupied space without erasing the wider account.

Because those records share one domain, staff move from a customer to the relevant unit, invoice or payment instead of copying identifiers between systems. One search covers customers, units, rentals, invoices, payments and other operational records, and the command bar over it navigates and filters. It never submits money, contracts or messages.

The facility map adds the reverse route: start at the drawn site, identify a unit, open whatever detail the reader is permitted to see. Permission is enforced per column, so that route does not quietly become a way around a role.

A relationship includes its difficult moments. When a payment fails or an invoice runs overdue, staff need the account context rather than an alarm. Past-due accounts progress through defined stages with stage fees, collection notes and promises to pay, and one operations queue gathers overdue accounts, lockout work, payment failures, disputes, undelivered messages and staff tasks into the day of work.

Communications go out by email, SMS or print from one template catalogue, with batches, per-recipient delivery tracking, inbound SMS and consent controls, and an undelivered message is kept as an operational exception rather than dropped. Rules over a typed fact vocabulary act within authority limits, with an observable run history.

Where a customer changes unit, debt continuity is checked by the transfer service, and an allowed arrears override needs the capability and leaves an audit record carrying a reason.

Across fifteen portal routes: view units, balances, invoices and payments, pay a balance, manage a saved card and autopay, upload KYC documents, read and sign an agreement, add a further unit, transfer, buy from the shop and start a move-out. That takes most of the routine what-do-I-owe traffic off the front desk.

Three things are still in development and are named rather than implied: changing to a larger or smaller unit, buying cover from inside the portal, and support messaging. They become public feature statements when the product and its tests demonstrate them, and not before.

Whether the system answers operational questions without a manual reconciliation. Which units does this customer control? Is the balance tied to an invoice history? Did a retry fail? Is a document awaiting review? Was that message delivered?

Then ask what automation is being sold. A scheduled receipt is not a workflow engine, and a Stripe card adapter is not an integration marketplace. Clear boundaries make a comparison more useful than an undifferentiated feature checklist, which is why the table below marks the boundary as carefully as the capability.

At the pipeline. There is no lead board, no deal value, no stage forecast and no configurable sales workflow builder. Lead attribution by channel exists, and abandoned booking sessions are staged with resume links, but attribution is not a pipeline and should not be read as one. A lead and deal pipeline is planned.

That shapes how a commercial enquiry is handled. A business asking about twelve units across three of your sites becomes a customer record with contacts and custom fields, and a reservation held against real inventory. It does not become an opportunity you drag between columns and forecast. If a sales team measures its week on a pipeline view, that view has to live somewhere else.