Adobe Stock

Your technology stack is what drives the work within your organization. As companies mature, more technology, applications, programs, and hardware creep into an organization. With the abundance of innovation in the multifamily space, it can be difficult to determine which budding technologies qualify as a solid fit for an organization.

While it can be tempting to add all of them, many operators have learned through trial and error that a more measured approach is required when building a tech stack. At the outset, the primary questions to ask are what impacts the tech will have on your team, on residents, and from a corporate perspective. These questions can be: Does it work as imagined? And does it make things easier, better, faster, or less expensive?

Essentially, you don’t want to inundate your team with anything that is potentially disruptive. You don’t want to provide residents with something that doesn’t add value to their experience. And any tech implementations also have to pencil out from a corporate perspective.

While that can serve as a broad guidepost, a successful approach to building a tech stack also requires a deeper dive into some of the details. Here are some must-haves for any technologies operators are aiming to add:

Ability to Integrate

Perhaps the No. 1 component is integration. While some innovations can work well as a stand-alone product, it is most beneficial when it can integrate with your property management system. Most important, it reduces the headache of working in one system and having to manually transfer the results into a second system. As most operators will know, double entry is the kiss of death for a property team.

For the tech to be effective, an easy way of getting the output from one system into another solution is paramount. Operators only have one system of record, after all, and it’s usually the property management system, so all information must seamlessly flow into it.

Ensure It’s the Proper Fit

When determining whether a technology will work at an organization, operators should build detailed and ultra-specific use cases to measure the technology. This helps ensure the software can do what you want it to do at a granular level. Oftentimes it’s during this detailed vetting process when it becomes apparent the tech doesn’t work in the way you envisioned. How associates imagine the technology—as opposed to its actual functionalities—often has a large impact on how the tech is used.

Operators can consider bolstering the traditional tech rollout process to ensure a solution is a proper fit and thoroughly understood throughout the organization. Most follow the basic methodology of implementing the software at one community, moving on to three more, and then going with a portfoliowide rollout. But scale often breaks things—meaning different users approach software differently and have varying expectations. Preventing this requires a deeper level of training that goes beyond merely how to use the software.

Train Robustly

While training teams on the functionality of a new software is a necessary initial step, it should only serve as a starting point. The training process should also communicate what outcomes the organization is expecting from the software, how the data will move from System A to B, where limits exist within the data, and what purposeful uses can be derived from it. Trainers rarely go into that level of detail with associates, and that’s where organizations often experience the biggest disconnect in building an effective tech stack. The training serves as a prime opportunity to communicate how work is imagined versus how work is done.

If the purpose of the tech is to improve operations and organizational efficiency, training beyond the functionality of the software is vital. Without training for the precise outcomes you’re seeking, it’s a virtual guarantee that at least 25% of associates will use software differently. In this case, it can be ambiguous as to which results truly qualify as a positive outcome. A key component to the next-level training is having a corporate culture in which asking questions is valued, and multiple modes of training are available rather than a one-size fits all approach.

Allow Proper Time

Hasty rollouts can be detrimental, so allowing proper time for any tech implementation is critical. Two factors can help operators determine how much time is needed for the rollout—the complexity of the software and the risk to operations. The more complex the software, the more time that should be allotted for the rollout. The same goes for the greater the risk to operations.

For instance, a pet technology or a digital parking platform qualify as nice-to-haves but are not generally critical to operations. But tech centered around payment processing or digital service requests is crucial to operations and typically more complex. More risk is usually associated with these types of platforms, so a lengthier rollout time would be more fitting for more operational critical technologies.

Risk can be assessed in two ways—resident risk and corporate risk. Resident risk centers around disrupting a frictionless experience, such as smart-home technology that actually makes things more complicated or a poorly executed service platform. An example of corporate risk is an inefficient payment platform that delays the payment process or causes incorrect data. The greater the risk, the more time that should be allowed for the rollout.

Building a tech stack is less about implementing as many innovations as possible and more about incorporating tech that will make a genuine impact—and tech that erases pain points rather than creating them. Organizations that take a consultative and resident-first approach generally experience the best results.