A framework to manage tenant/owner roles in co-living properties

 

A few weeks ago the Bangalore metropolitan issued a notice saying there won't be water supply in the city for 2 days. Some SimplyGuest properties have their own bore-wells and don't depend on Cauvery water, but all others do. Tanker water is easily available in some places but in places like Bellandur there is high demand and they jack up the prices and still don't deliver water. Although we made alternative arrangements in all the properties, we still had to inform the tenants that may be affected by it just in case if there was a hiccup in supply. Large scale notifications aren't very precise; some unintended customers may receive the communication while some customers that need to be notified may not receive it.

A home is where living happens; there is constant activity supporting it. As a result quality keeps moving up and down; mostly down if unchecked. When something goes wrong — it always does — it needs to be fixed; People require water, and it runs out. People need electricity and there is load-shedding and a host of other things that will interrupt power supply. Prolonged usage of bathrooms create plumbing issues. Garbage may not get cleared, especially in Bangalore. Lifts stop working or their lights go off. Environmental changes alter living conditions.

Every house comes with a set of people who live in it, or own it, or somehow has some interests in the property. Tenants, House Owner, Security, Housekeeping staff, Plumbers and Electricians, Gardener, etc. You need a water tanker guy who fills water when sump runs dry; at times there could be a specialized service personnel like a solar heater expert. Each of these parties have some interests in the property; they either provide service or consume it. Even a small property will have anywhere between 10 to 30 people of various roles. Large apartments have 1000s of people. How do you manage them?

People, Roles, & Properties

SimplyGuest now manages 100s of houses professionally, all kinds of houses: apartments, purpose-built-accommodation (PBA), villas, single rooms, few houses in a building, all houses in a building, etc. We have developed a framework that groups these people based on their roles. Every property comes with a default set of roles, but we can add to this list. Some of these groups are automatic; their members are added automatically by the system and you can't add members to it manually — for example tenants and house owners. However, we can create sub-groups within these groups. For example, if a property is large — like a hostel — the property manager may be interested in creating a group that consists of only vegetarians, or people who go to night shifts, etc. SimplyGuest welcomes all kinds of people without any discrimination.

Roles get aggregated at higher levels; for example if a building has 10 flats, all its tenants become tenants of the building itself, and these can be used for targeting a bigger pool of users. Property roles can be set at an area/locality level too. For example, who are electricians in Koramangala 1st Block?

Roles have permissions

The roles, and in turn users that belong to the role, will have a set of permissions. A house owner may want to know if a new tenant is moving in or when an existing one is moving out; that helps him setup the property and plan cleaning services. The tenants will be interested in knowing if their cook is going on leave or when is the next garbage clearance scheduled? These are restricted permissions; a house owner should receive notifications of his flat, not any other flat.

Granular Control

A tenant of a shared apartment — she may have rented a bed in a 3 bedroom apartment — may be interested in knowing if anybody else are moving in to her apartment. This can be even more granular. She may just want to know who is moving in to her room and not care about movements in other rooms. Some properties are fully managed by SimplyGuest, and in these cases owners don't bother to know about tenant entry/exits, but some are operated by owners themselves. These property categories require different set of permissions.

Channels

As and when an activity happens related to a property: a tenant moves in, someone makes a booking, or an electrician schedules a service visit, a message is sent to an appropriately named Channel. Every property gets a set of predefined channels at the time of setting up. Here is a partial list:

  • tenant.will-move.in
  • tenant.will-move.out
  • tenant.moved.in
  • tenant.moved.out
  • flatmate.will-move.in
  • flatmate.will-move.out
  • flatmate.moved.in
  • flatmate.moved.out
  • visit.scheduled
  • visit.completed
  • ticket.opened
  • ticket.closed
  • ticket.action-taken
  • service.visit
  • sg.expense
  • flatchat

A role is given access to some of these channels. The admin — usually the property manager — can decide to revoke a role's access to a channel at any time. If a role has a permission, say 'tenant.will-move.in' the users of that role will have an option of receiving notifications. If they don't want to receive they can opt-out of them, but they will always have that access. Occasionally the property manager or the system may want to send a push notification — say a payment reminder, or a notice to vacate. The push messages will always reach the recipients, even when the user has disabled all notifications.

Putting it all together we can create a nice matrix that shows which roles have what permissions and if they have subscribed to these channels or not.

Bicycle on Rent at SimplyGuest.com

This framework — we call it PRP internally — makes it easy to send notifications. Right communication requires precise targeting, and PRP provides that. We can target precise set of people to communicate on a particular subject. This targeting makes operations friction less especially when two people — either within the house or between properties — want to share expenses. For example, common areas electricity bill may need to be split among all houses in a building: you can create a group in PRP.

Access control and sending notifications may appear like the primary purpose of PRP at this point, but it may evolve in to something bigger. The PRP opens up a spectrum of possibilities. We have already built many interesting things on top of PRP.

  1. The city corporation issues a notice to a building for not segregating garbage? Send a message to PropRole: Tenant.Person
  2. The party hall is booked by someone? Or, the housing society issued a warning to all residents that there won't be water supply for 2 days? Relaying this message is easy! Send a message to that building's PropRole: Tenant.Person
  3. What if the owner of a parking lot decides to re-arrange the parking lots? Send a message to Tenant.Car
  4. House services may require permissions from tenants. Notifying all the affected people and taking their permission before the work can begin is a difficult task, especially for two reasons: nearly all our tenants go to work, and secondly, service staff may have multiple jobs scheduled and coordinating becomes difficult.
  5. If we have a floor-wise WiFi connection we can create a sub-group for every floor from the tenants group and use that to split WiFi expenses.

Future

PRP framework sits at the core of our technology. We are designing an automatic visit scheduling, something similar to how Uber does its ride scheduling. The auto-visit-scheduling software wouldn't be possible if not for PRP and its accurate targeting. At the same time it allows customers to set preferences on what notifications to receive and shutdown noise.

Schedule a visit to a SimplyGuest propert
Schedule a visit to a SimplyGuest propert

Got questions or comments? Feel free to email me.