We are very excited to formally release our new product – Reonomy for Teams! Our Product and Engineering teams have been hard at work over the last few months building new functionality and feature access on the Reonomy Platform.
Neil Newman, an Engineering Manager here at Reonomy, was absolutely essential in understanding and creating Teams specific features that enhance collaboration and clarity for team workflows. Below, Neil gives the full rundown of how and why we built out this new product.
Why Create a Product for Teams?
Today we’re launching Reonomy for Teams to give our small and medium-size business customers the tools to be successful in CRE, together. For much of my career, I’ve developed tools to make businesses more efficient and able to solve problems collaboratively.
I’m excited to share some of the insights and thinking behind the product and give a look inside our process. Reonomy for Teams is differentiated from Reonomy for Individuals in the way of collaboration, alerting, and self-management.
The Advantage of User-Input Data
When discussing what would make Reonomy for Teams successful with some of our users, we found that user-input data was most important. As a user, notes that I add, properties for which I unlock contacts, and labels that I create are all mine, private, and locked away from other users. That said, there are a lot of situations where I might want to share something with another user.
Here’s an example of a note I might add to a property in Reonomy for Teams, tagging my co-worker Jamie. I already unlocked this property, got the contact information, and I’m ready to move on and do more prospecting. Meanwhile, Jamie gets an email with the note, and is able to go right to the property and see what they have to do.
Previously, I would’ve had to send a link to the property to Jamie via email, in a separate system, and Jamie would have to log into Reonomy, unlock the contact for the property on their own, and take action.
This simple interaction shows how Reonomy for Teams drives efficiency through the ability to share in the content created. Another important aspect of this interaction is the alerting – we’re using emails to get a team engaged in Reonomy while making sure they have context in-line with property data.
Steps to Adding New Functionality
Looking under the hood, this was accomplished by leveraging our new and robust API. The API considers a team as a group – groups are entities composed of users and/or other groups. A group with many users is a team, unlocking all of the features discussed here. In order to represent the complex relationship of groups and users, we created componentized code referenced in many places, and leveraging the LTREE data type.
LTREE allows us to represent groups in a tree structure. When you create a note, unlock a property, or add a label, we store the hierarchical relationship of that group to its parents, as well as your user. Combining this with a Generalized Search Tree index, we can construct a query to look for content that was created in your group, or any subordinate group related therein.
Using LTREE, for a user in Group B, we’d filter on LTREE 1.2, finding our group 1.2 as well as its descendants, 1.2.3 and 1.2.4.
It isn’t enough to simply create this pattern. With several shareable data types, such as notes and labels, we don’t want to duplicate the same code over and over again. Doing so would potentially mean propagating errors, and subjecting the codebase to bloat and later technical debt.
Instead, we utilized method resolution order (MRO), otherwise known as class inheritance, to create a generic shareable content “mixin” that can be added to code for any shareable entity. This allows us to write and maintain one set of methods to enable sharing and partition the content between different teams, while still enabling shareable content and power future, more complex organizational structures.
MRO Code Diagram
class Mixin: def apply_filters(self, query): return query.filter(group.contains(USER_GROUP)) class NoteComponent(Mixin): def get_notes(self): return self.apply_filters(NOTES.objects)
This is pseudo-code exemplifying inheritance. By inheriting from “Mixin,” “NoteComponent” has access to the functions in contains, such as “apply_filters.” We can then re-use “Mixin” in other places, such as a “LabelComponent”
How Teams Features Fit Your Workflow
Now – let’s go one step further. My team is encompassed of Jamie, Sam and I. I prospect, Sam does research and qualifies leads, Jamie does outreach and hands off to back to me when deals are ready to close. We’ve set up a simple workflow for this with 5 shared labels:
With my team spending their entire day in Reonomy, they can focus on the properties in their label. Instead of inundating my team with emails, I add my properties to “Hot Leads!” when they look interesting.
Sam is constantly watching this label, and as properties come in, they do their due diligence and add them to “Qualified” if we should reach out. Jamie sees these properties as they come in, and is ready on the phones to make calls and win business.
Meanwhile, I watch my “In Contract” label to see what business we’ve won that needs to close. With Reonomy for Teams, I’ve created a powerful workflow tool that can drive my team to greater efficiency, with us all synchronized and with Reonomy as our source-of-truth.
Improved Workflow Management
Another point of feedback we’ve heard is around the management of teams. Team leaders want to add and remove people from their teams easily, and want to see metrics of their team’s usage and allocate contact credits appropriately.
With the Teams Management page, we give team leaders the ability to self-service their team membership. We can also show you how your team is using the platform. Using these insights, you can drive business more effectively, and know when Jamie needs some backup on the phones, or Sam needs some help doing research.
Reonomy for Teams is only just getting started. We’re excited for you to see what comes next as we continue to improve and add new features!