Almost every guide to putting property data into a CRM is written by someone who sells houses. That is fine if you sell houses. It is a problem if your business is letting the same room to a different person every year, because the model those guides describe assumes a property is a thing that transacts once and then leaves the system. HubSpot's Listing object is the right home for property data in a PBSA or BTR operation. The default way it gets set up is not.
Listings is a native CRM object that ships in every HubSpot portal, switched off. A super admin turns it on in about a minute: More, then Data Management, then Data Model, then Edit data model, then Activate listing. It is one of four pre-built industry objects HubSpot maintains, alongside Courses, Appointments and Services, and unlike a custom object it does not require an Enterprise subscription. If you are on Professional and keeping property data in a HubDB table, a spreadsheet, or the address typed into a deal name, that alone is worth knowing.
The trouble starts immediately after activation. HubSpot offers a real estate data model recommendation that configures everything in one action, and most of the guidance written around the object follows the same shape. It is built for selling: buying and selling pipelines, sale price and listing type as core properties, days on market as the headline metric, and a listing feed arriving from a sales portal. There is no vendor and no buyer in your business. Apply that template to a student portfolio and you inherit two pipelines you will never use and a field structure that answers questions you will never ask.
So activate manually and build the properties deliberately. The two decisions below are the ones that matter, and both get considerably harder to change once data exists.
Selling property has an easy answer. One address, one listing, one sale. A PBSA scheme does not. One building might hold 600 beds across eight room types, and a BTR block 300 apartments across six layouts. So what is a listing? Three answers, and two of them are good.
Building level. One record per scheme. Clean for a website index and useless the moment someone enquires, because you cannot say what they enquired about or whether it is still available. Rule it out.
Room type per building. One record per room type at each scheme: Bronze En-suite at Building A, Studio Plus at Building B. It matches how you market and how you price, and it is consistent with the information you actually display, because the images, the wording and the features are the same across the type. A good option, and the lighter of the two.
Bed or unit level. One record per lettable space, mirroring the PMS. The most granular option, and the one we lean towards.
The grain decides what you can associate, and that is the whole argument. At bed or unit level, enquiries, contracts and contacts attach to the actual space. You can see how much interest one unit has attracted, what it has been priced at across several contracts, and who has lived in it. You can cross-sell a specific unit because the floor or the aspect is worth more, the one facing the sea, the one nobody overlooks. A room type record averages all of that away.
It does stray into duplicating your PMS, and that is the honest trade. What you buy with it is scope. Occupancy graphs, third party services, communication with service companies: you can build those on your own HubSpot records rather than waiting for your PMS vendor to put them on a roadmap. Reporting works the same way round. With unit level records you can aggregate up to room type whenever you want, and you cannot go the other way.
Two things to hold onto if you go this way. The first is that the website is not a reason to avoid unit-level records. Dynamic pages populate straight from the Listing object, so a page per unit is generated rather than built. Put the room type content in a HubDB table, the images, the wording, the feature list, and every unit page inherits the shared detail while carrying what is genuinely its own: the floor, the aspect, the price, the periods it is open for. One place to manage the copy, unique pages per listing, and no forty-page maintenance job.
The second is that allocation stays in the PMS. The CRM answers what someone enquired about, what they were quoted and whether they booked. The PMS stays the operational record for the tenancy itself.
The standard advice is to separate status from availability, so that "let" and "hidden from the website" are not the same field. That is right, and nowhere near enough for letting. A space is not simply available or unavailable. On any given day in February it is let for the current academic year and open for the next one at a different price. Both are true at the same moment.
Two separate questions hide inside that, and they want different answers.
What shows on the website, for which period. This is a visibility question. The cleanest handling we have found is to carry the lettable periods on the record itself: a structured field holding each period you are marketing, with its price and its state, rather than a single availability toggle. The website asks for a period and gets back the units open for it. There are other ways to model the same thing, including one listing record per letting year associated to a parent scheme, which keeps every record clean at the cost of multiplying record counts. Either works. What does not work is one on/off flag, which hits the wall in week two of the rebooking window, when the same record has to be both let and selling.
How the portfolio performed, year on year. Different question, different structure. Answer it from deals, or by rolling up contracts to see which nights were actually booked. Be honest that a good deal of this is a report your PMS already produces and may keep producing. Where HubSpot earns its place is a small custom object per letting period carrying booking date, rate, first occupied, last occupied and days vacant. That gives you same week last year, void nights by building and rate movement over time, sitting next to the enquiry data that explains the numbers, which is the part the PMS cannot do.
Sales-led guides treat a listing carrying several deals over its life as a footnote about rentals. In letting it is the entire point. A unit carries a deal every year it lets, and that is what makes re-let rate, rebooker share, void nights and year-on-year velocity answerable from the CRM instead of from a spreadsheet somebody rebuilds every August.
Association labels earn their keep here. On a single listing, one contact can be labelled enquirer, another viewed, another applied, another current tenant, rebooker, or past tenant. Association limits are worth setting too. If a studio can only ever have one current tenant, configure that association as one-to-one and HubSpot enforces it. Data quality by configuration rather than by training.
Contacts are only the start, and this is the part most builds miss. The listing should also associate to tickets for every service request raised against that space, to deals for every booking it has carried and every one still ahead of it, and to leads for the enquiries it has attracted and will attract again. Do that and the record stops being a description of a unit and becomes its history.
That history is the asset. When a unit comes back to market you can see how many viewings it took last time, what kind of resident enquired, what they actually paid and how long they stayed, without leaving the CRM. That is benchmarking you can price against and prospecting you can target with. None of it exists if the record is a room type, and none of it survives in a spreadsheet.
Pipelines follow, though not the way the sales template suggests, and not the way most people expect.
In PBSA, do not build a separate rebooker pipeline. Where a PMS is in place, the booking process for a rebooker is the same process as a new let: same stages, same steps, same paperwork. Splitting it in two duplicates the build and leaves you reconciling two of everything at reporting time. Map the rebooker journey with custom properties on the deal instead. You keep one pipeline and still get rebooker share, rebooking conversion and same week comparison.
In BTR the ground has already moved. A renewal used to be a separate motion on its own clock: a deal raised two or three months before the tenancy end date and worked towards a decision, which was a clean case for a second pipeline. The Renters' Rights Act took the trigger away. Tenancies are periodic now, so there is no fixed end date to count back from and no renewal event to progress a deal towards. Anyone still holding a renewal pipeline is running a stage set nobody walks through.
What replaces it is retention. A rolling tenancy ends when the resident decides to leave, so the things worth modelling are notice given, satisfaction, rent review and the reason behind a move-out. If you build a second pipeline in BTR, build it around retention and re-let rather than around a date that no longer exists.
Nominations and group bookings are the real third motion where you run them. Different stages, different timelines, completely different economics.
Once listings are real records, workflows can act on them. The triggers in the sales-led guides are price changes and sixty days on market. Yours look different:
That last one matters more than the rest. A bed unlet in February can still be filled. The same bed unlet in August cannot, because the void is no longer recoverable inside the cycle. A generic days-on-market alert treats those two situations identically. A calendar-aware trigger does not.
Reporting comes with it: enquiries by room type, pre-let rate by building against the same week last year, and conversion by source.
Your system of record is the PMS, whether that is Concurrent, StarRez, RealPage or Yardi. StuRents, Rightmove and the rest are distribution, not source. The sync runs one way, and HubSpot never becomes the place where somebody edits a room.
The mechanism is straightforward. HubSpot's listings API supports batch create, update and upsert, and reads up to 100 records per request. A nightly batch upsert of the full feed keeps HubSpot current without anyone tracking which records are new and which changed.
One warning from running this in production. Use a stable identifier from the PMS as the matching key and store it as a listing property. Never match on address or room name. The first time somebody writes "Flat 3b" where the feed says "Flat 3B" you have two records, and by the time anyone notices, both have enquiries attached.
It is not a PMS. Tenancy agreements, right to rent checks, deposit protection, maintenance and rent collection stay where they are.
That boundary is moving, though. Commerce Hub takes payments, and contracts now live inside HubSpot to manage an ongoing agreement, so parts of the money and paperwork side that used to be automatically out of scope no longer are. The customer platform is edging towards running more of this end to end. Worth watching rather than betting the model on today.
It does render on your website, with a caveat. Activation on its own gives you records in the CRM and nothing public. The pages themselves are a smaller job than people expect, for the reason set out above: dynamic pages generate from the Listing object and HubDB carries the shared room type content. Search, filtering and the enquiry routing behind them are the real build. We have PBSA sites running exactly this.
Historic reporting starts the day you switch it on. Activating mid-cycle costs you the year-on-year comparison you most want, which is an argument for doing it now rather than in March.
And the real estate template is sales-shaped. Take the object, leave the template.
Switching the Listing object on costs nothing and takes a minute. Restructuring thousands of listing records after a year of enquiries have attached to them does not. The activation was never the decision. The grain of the record, and the way availability carries a letting period, are the decisions you cannot easily reverse.
Agree both before the first import. Everything after that is configuration.
If you are moving property data out of spreadsheets and into HubSpot, the model is worth twenty minutes with someone who has built it for letting rather than for sales. Getting the data in is the other half of the job, and that half is already productised. StaySynced runs the nightly sync from your PMS into HubSpot, keyed on the PMS record rather than the address, so your listings stay current without anyone maintaining them by hand. See how StaySynced works.