Why It Matters
Built for hosts who scale, by hosts who scale.
Several digital guidebook tools treat each property as a separate guidebook copy. You set up the same articles for each one, maintain them in parallel, and watch them drift out of sync over time. SmoothStay was built differently — because we run multiple properties ourselves and we needed it to work.
The architecture is structured around three principles: share content where it makes sense, restrict content where it doesn't, and let the host decide which is which on every article. Welcome to your property might be one shared article that fills in the property name dynamically. What to bring might be five different articles — one per property — because Tulum's climate isn't Washington DC's. Local recommendations are always property-specific. The system supports both patterns equally, with tags for sharing, property restrictions for one-off content, and the Data Dictionary for dynamic details.
Branding follows the same flexibility. Set your account-level defaults once, and every new property inherits them. Override per property for the exceptions — a different brand, different colors, a different language. The defaults give you consistency. The overrides give you flexibility. You scale without losing either.
This is what multi-property infrastructure actually looks like — and the reason hosts running 5, 10, or 20 properties consistently choose SmoothStay over the alternatives.
How it Works
1
Add your properties
Create each property with a name, address, and basic profile. Properties are the unit your account is organized around — every guidebook, reservation, and share link is tied to a specific property.
2
Set your brand defaults once
In Brand Settings, set your default branding (logo, colors), default language, default AI tone, and default OTA compliance sources. Every new property inherits these defaults — no per-property setup required.
3
Decide what to share, what to keep specific
For content that works across properties, write one article and tag it with the relevant properties — use Data Dictionary placeholders for details that change per property. For content that's location-specific, write per-property and restrict visibility accordingly. The system supports both patterns; the choice is yours per article.
Pricing
Multi-property management is included on every paid plan, with pricing that compounds favorably as you scale.
How to Create Guidebook Content in a Multi-Property Setup
Tag your properties before you tag your articles. Decide your tag taxonomy early — by region (Playa del Carmen MX, Washington, DC), by property type (beachfront, urban), by brand, or by whatever logic fits your operation. Tag every property accordingly. Then when you write articles, the tagging decisions become obvious.
Choose flexibility over uniformity. Some articles work perfectly when shared — welcome messages, house rules, check-out steps. Others are property-specific by design — what to bring is different in Tulum versus Washington DC, local recommendations are unique to each location, what we provide may be similar but written specifically per property. A typical multi-property portfolio runs 40 to 60 articles total, a mix of shared and property-specific — not because the system forces it, but because that's what good hospitality looks like.
Use property-level overrides sparingly. The defaults handle most cases. Override only when something genuinely differs — a different brand, a different language, a different OTA channel mix. The fewer overrides you maintain, the easier your portfolio is to scale, audit, and update.
Related features
