Mailchimp Segmentation for Self-Storage: Message the Right Customers
Message former customers, active customers, or any group you choose.
contents
Most modern storage management software already sends transactional messages automatically: a booking confirmation, a payment reminder, a move-out notice. That’s not what this post is about.
Mailchimp solves a different problem: messaging a specific group of customers, once, on your own terms. A win-back discount to everyone whose booking ended in the last six months. A holiday hours notice sent only to customers with an active unit right now, not people who left years ago. A price change communicated to one facility’s customers and not another’s. None of that is triggered by a single event happening to a single customer. It’s a deliberate campaign to a segment you choose.
To build campaigns like that, Mailchimp needs your customer data kept current, with fields you can actually filter and personalise by. Getting that data across is an API integration between whatever holds your operational records and Mailchimp’s own API. This post covers how that works and how to set it up well, regardless of which storage software you run. The Zapier automations post covers a related idea, moving operational events into other tools as they happen; this one is specifically about keeping a Mailchimp audience populated and segmentable.
If you haven’t read An Introduction to APIs yet, start there.
What "integrating via API" means in practice
Your storage management software holds operational data: customers, bookings, invoices, payments. Mailchimp holds marketing data: audiences, contacts, merge fields, automations. Neither system knows about the other by default.
An API integration is the bridge. Your storage software exposes an API (Kinnovis customers use Kinnovis Connect, included with every account); Mailchimp exposes its own Marketing API. A third party, usually middleware such as Zapier or Make, or a small custom script, sits between the two and moves data in one direction: from your storage software into a Mailchimp audience.
How your customer data gets into Mailchimp
The direction matters, and it isn’t always symmetrical.
Mailchimp’s Marketing API supports webhooks, so Mailchimp can push events out the moment something happens on its side, an unsubscribe or a bounce, for example.
Many self-storage platforms don’t support webhooks on the way out. There’s no push. Anything moving from your storage software into Mailchimp has to run on a schedule instead, known as polling: your middleware calls an endpoint periodically, checks for anything new or changed, and passes it to Mailchimp’s contacts endpoint.
This is a limitation worth planning around rather than a flaw to work past. A five or ten minute polling interval is fine for keeping an audience current for segmentation. It isn’t the right foundation for anything that needs to fire the instant something happens, which is what your PMS’s own triggered emails are for.
What data actually moves and what it's for
Most storage-to-Mailchimp integrations work with three types of data:
| Data type | What it becomes in Mailchimp | Used for |
|---|---|---|
| Customer records | Audience contact, with merge fields for name and unit details | Personalising any campaign |
| Booking or contract status | A segment field: active, past due, expired and so on | Targeting who a campaign reaches |
| Invoice or payment status | A segment field | Targeting a wider communication, such as an autopay sign-up push to accounts with a history of late payment, distinct from the automated per-invoice reminders your PMS likely already sends |
Whatever your source system, build segments around the exact status values it returns rather than assuming finer distinctions exist than it actually provides.
Setting up custom fields and merge tags in Mailchimp
The sync only pays off if Mailchimp has somewhere to put the data, and that means setting up fields before the first sync runs, not after.
- In Mailchimp, go to Audience > Settings > Audience fields and |MERGE| tags.
- Add a field for each attribute you want to segment or personalise by. For most operators that’s booking status, facility or location, unit type, and move-in or move-out date.
- Pick the right field type. Dropdown works best for status fields, since it keeps your segment conditions to a fixed set of values rather than free text that can drift.
- Mailchimp generates a merge tag for each field automatically, for example
*|BOOKING_STATUS|*or*|FACILITY|*. You’ll see the exact tag under “Put this tag in your content” next to the field. - Your middleware maps each source field to its Mailchimp merge tag when it creates or updates a contact, so fields populate automatically as records sync rather than being typed in one at a time.
- Once populated, build a segment using field conditions: “Booking Status is Expired” and “Last Changed more than 90 days ago” for a win-back list, or “Booking Status is Active” and “Facility is Vienna” for a location-specific announcement.
- Use the same merge tags inside the campaign content itself to personalise it, for example “Hi |FNAME|, your unit at |FACILITY| is still available if you’d like to come back.”
Practical use cases
Win-back campaign. Segment on booking status Expired or Canceled, plus a move-out date within the last few months. One email, one discount, sent once to a defined group, not the whole list.
Facility-specific announcement. Holiday hours, a policy change, a local event: segment on booking status Active and facility, so only current customers at that location see it.
Reactivation nudge. If lead data is also synced, segment enquiries that never became a booking, separately from customers who are already active, since the two groups need different messages.
Price or policy change. Segment by unit type or facility so the message reaches only the customers it actually applies to.
None of these need data written back from Mailchimp to your storage software. The connection stays one-way, and that’s sufficient for every use case above.
What you need to set this up
An API key from your storage software, scoped to read-only where that’s an option, since Mailchimp doesn’t need to write anything back.
A Mailchimp account with API or OAuth access, and an audience with the custom fields you plan to populate already created.
A middleware layer. Zapier or Make cover most use cases without custom code. Higher-volume operators may prefer a small scheduled script instead, for more control over the polling interval and error handling.
How often the sync checks for updates (the polling interval). Every five to ten minutes works well for customer and invoice data. Anything without a date to check against, such as units or locations, has to be fully re-checked each time rather than just the changes, so that can run less often.
Where this has limits
If your storage software doesn’t support webhooks, which is common, there’s no way to make this instant. Plan segmented campaigns around a short data delay rather than promising real-time triggers, and lean on your PMS’s own triggered emails, or an event-based automation approach like the one covered in the Zapier automations post, for anything that genuinely needs to fire the moment an event happens.
Mailchimp’s own API access and send limits depend on your Mailchimp plan, not on your storage software. Check your plan’s API request allowance before setting a polling interval, particularly if you’re polling several resources on a tight schedule.
How this looks with Kinnovis Connect
If you’re a Kinnovis customer, here’s the concrete version of everything above. Kinnovis Connect is our public API, included with every account, and it doesn’t support webhooks, so the sync runs on polling: GET /customers?filter[updatedAt]=... on a schedule of your choosing. Booking status only ever returns one of six values (active, scheduled, past_due, canceled, expired, incomplete), which maps directly onto the segment fields described above. An API key can be scoped to read-only (reader_api) for this use case, since nothing needs to write back.
Frequently Asked Questions (FAQs)
Yes, if you want to message a defined group of customers on your own schedule, rather than react to something that just happened to one customer. The two are complementary: your PMS handles what happens per customer, per booking. Mailchimp handles messaging whichever group you choose.
Something in between, in most cases. A middleware layer, typically Zapier, Make or a small script, sits between your storage software’s API and Mailchimp’s API and moves the data across.
No, for the setup described here. The connection only moves data one way, into a Mailchimp audience. Nothing written or changed in Mailchimp writes back to your operational records.
Most storage platforms don’t support webhooks, so data moves on a schedule (polling) rather than the instant something changes. A five to ten minute delay is standard and doesn’t affect segmented campaigns, which aren’t time-critical in the same way a triggered email is.
Once status data is synced as a custom field, build a segment in Mailchimp using that field, for example “Booking Status is Expired.” See the custom fields section above for setting the field up before your first sync.
Not for the integration itself. Zapier or Make cover the data sync without code. The part worth taking time over is the field mapping in Mailchimp, since a segment is only as reliable as the field it’s built on.
API Academy
Zapier Automations Self-Storage Operators Actually Use
HubSpot for Self-Storage: Segment Customers and Track Renewals as Deals
Turning Real-Time Unit Availability Into a Marketing Asset
Get Started today
Unlock the true potential of your
self-storage facilities
Kinnovis. Designed to make facility management simple.
