When implementing large-scale technological or process improvements across a multifamily portfolio, starting with a small pilot group of communities can help iron out the kinks associated with these major changes. Unfortunately, selecting communities for a pilot is no simple task. In the past we’ve seen some of our customers struggle to run effective pilots of an AI-enabled centralized services model due to poor selection of pilot communities. This has resulted in lower than desired adoption and engagement, slow deployment of new software, and negative impact on technology ROI. With that in mind, we asked Jacob Kosior, Vice President of Client Strategy at EliseAI and former VP of Centralized Services at Cardinal Group Management, to share what factors he took into account when designing pilot groups for AI and centralized services. Here’s what he had to share with us.
Community Size and Complexity
When selecting properties for your centralized services pilot it’s important to think about choosing communities of representative sizes and complexities to other communities in your portfolio. If you only select your largest or most complicated communities the results and learnings from the pilot won’t necessarily be applicable across your portfolio, and might result in your team making incorrect assumptions that negatively impact the larger rollout. Testing new processes across a diverse and representative group of communities can help your team gauge how well the centralized support model will scale across community types in your portfolio, from small to large and from simple to complex operationally.
Resident Demographics
Each resident profile is going to have different expectations and willingness to test new systems and processes, so it’s important that you take demographics into account when piloting out a centralized services model and the new solutions that enable it. For example, your student residents may be more receptive to learning how to use new technology than senior residents. While your initial inclination may be to test out a centralized model and the software that enables it on a resident profile that you feel may be amenable to change, doing so won’t necessarily represent how your other resident profiles will react. With that in mind it’s important to build a representative demographic set of communities that will give you a clear picture of how all your different resident profiles will react to a centralized service model, rather than only selecting demographics you feel will be most receptive to changes.
Operational Stability
Consider the current performance of the communities before you go about implementing changes. If a community is already struggling with turnover, maintenance issues, financial discrepancies, or inefficient processes, you’re already at a disadvantage when trying to make improvements. With that in mind, selecting high-performing, operationally stable communities for your pilot group ensures that if the pilot goes unsuccessfully that it was the pilot itself that was flawed, not pre-existing issues at the communities you selected. Otherwise, it may be difficult to separate the preexisting issues from the impact of the pilot program.
Technology Readiness
Any push towards implementing AI or centralization in onsite operations is going to require the adoption of new technologies, so it’s important to consider the technological capabilities and readiness of the communities you select for your pilot. When adding new software like AI assistants, CRMs, and communication platforms, you need to ensure that the existing technology in place in these communities will smoothly integrate with new solutions. Throwing a bunch of new software at less tech-savvy members of your team and expecting them to seamlessly transition from the old tools to the new ones is going to create confusion and negatively impact community performance. With that in mind, picking communities that are technologically equipped for a pilot, as well as open to trying new technologies, is crucial to ensure you get the best results out of your program.
Onsite Team Buy-In
It doesn’t matter how strong the operational need for centralization and new technology is if your onsite teams don’t buy-in to participating in a pilot. When choosing communities for a pilot it’s crucial that you choose communities with onsite teams that are open to the idea of adopting new technology or centralized services to create added efficiencies. Otherwise, you’re setting your pilot up for failure.
High-performing onsite team members, particularly those identified for future leadership roles, are ideal candidates for pilots. They’re generally more open to adopting tools that enhance their efficiency and are more likely to actively engage in the process, which in turn provides valuable insights for how to improve the centralized support model. In addition, their quality of their feedback can help you understand how they’ll handle new responsibilities as they progress through their career.
If you’re looking to increase the buy-in from your onsite teams, it’s important to emphasize the benefits of AI and centralization and how these new approaches to onsite operations will improve their day to day roles and responsibilities. Start by explaining that centralization will allow them to focus on higher-level aspects of their job, like client deliverables, developing strategies, building relationships with residents, and improving the community experience, while offloading repetitive tasks to specialized teams. As we covered in our post on preparing your single family rental portfolio for centralization, the way you present the centralization effort and the talking points you provide to organizational leaders can have a significant impact on how receptive your onsite teams are to increased centralization.
Geographic Location
Geographic diversity is another factor to consider when selecting pilot communities. Centralized support can vary in effectiveness depending on the location of your communities and local regulations in these areas, so including communities from different regions can help your team gain a more comprehensive understanding of the impact of a centralized operating model. If you choose communities that are too geographically similar you run the risk of your pilot data being skewed or incomplete due to unique characteristics of that geography. Picking a group of communities spread across a variety of geographies ensures the learnings and takeaways from your pilot are broadly applicable.
Client/Ownership Support
For third-party managers looking to implement a centralized services model, ensuring property owners are bought in is crucial when designing an initial pilot set. As we’ve discussed throughout this piece, adopting a centralized service model entails a variety of expenses and financial investments that an ownership group will have to sign off on. Trying to successfully execute a pilot in communities with owners who aren’t eager about the prospect of centralizing their property management operations is going to be an uphill battle from the beginning. Focus on selecting communities for your pilot with ownership groups that have demonstrated their willingness to try new strategies and optimize their operations in the past if you want to set your pilot up for success. Then, you can use your learnings (and overall cost savings data) from the pilot to warm other ownership groups up to the idea of centralizing their operations as well.
Performance Metrics
In order for a pilot to be successful, you need to have the means to collect relevant data and measure the impact of the changes on your communities’ performance. Otherwise, it might be difficult to justify a shift to a centralized services model, or to get further owner buy-in for subsequent changes. Make sure the communities you select for the pilot have the structure in place to easily track and measure performance metrics both before and after you begin centralizing. That way, you can draw actionable conclusions on the impact of the pilot on leasing velocity, resident satisfaction, maintenance response times, community financial performance, and more. Subsequently you can package and distribute this data to ownership groups in your portfolio in order to get them to agree to piloting a centralized services model.
Existing Pain Points
When selecting communities to pilot a centralized services model, try to identify communities that have specific pain points that centralization is meant to address, including high staff turnover rates, slow response times, low resident satisfaction, or poor leasing velocity. If your pilot can make a demonstrated impact on these key areas at communities with these existing pain points, it can help you make the case for further adoption of a centralized services model for your portfolio. Choosing to pilot a centralized services model in high-performing communities might not allow you to demonstrate the full potential for improvement in the way that choosing communities with pre existing issues does.
Communication Channels
Communities that already have established communication channels between onsite teams and regional or corporate offices make good choices for a centralized services pilot. The fact that these teams are already accustomed to working with remote support structures makes them good candidates for a model that relies heavily on specialized remote teams. Trying to have teams entrenched in the traditional property management model quickly learn to collaborate with specialized remote support teams can result in friction, lower than desired adoption, and delayed communications. Look for communities with strong existing communication channels and relationships with regional offices to pilot out your centralized services model.
Next Steps: Enabling a Centralized Services Model Pilot with AI
Taking these factors into mind when selecting pilot communities for centralized services can go a long way towards setting your pilot up for success. At the same time, it’s important to consider whether the technology your organization is using can help your centralized teams efficiently scale their impact across your portfolio. For Jacob and his team at Cardinal, that meant implementing a variety of solutions from EliseAI to support their centralized staff. Whether it was using LeasingAI to help centralized leasing agents deliver consistent, personalized follow-ups and lead nurturing, or choosing ResidentAI to support customer account specialists with bookkeeping and delinquency reduction, AI has been a key part of enabling Cardinal’s centralized teams.
Want to learn more about how deploying AI can help you implement a centralized services model at scale? Fill out the form below to get in touch.