Picking SaaS: 7 Questions to Evaluate Every New Business System

Finding the right systems for your business can be as difficult as it is frustrating.

A Google search for “CRM”, “property management software”, or “marketing automation platform”, or any other solution returns a seemingly infinite number of viable options.

Each service offers different packages. Some services are free until you hit a certain tier. Others provide no visibility into pricing and simply instruct you to “Contact Sales”. And does every integration have to be done with a third-party?

Clicking into each service’s website you can usually find a nice product page outlining the different tiers, the features offered within each tier, and the pricing.

Going one step deeper, there are reviews of the services, which are equally confusing. How is “usability” rated? Why does each review site seem to have a certain service in their back pocket? What are the reviewer’s incentives for approving/disapproving of a system?

The result? Never good.

Either we waste precious time and money researching and trialing new systems only to find they don’t work for one reason or another or throw our hands up at the complexity and enormity of the task only to fall back on the systems we feel comfortable with - never extending our domain knowledge of what’s out there.

With business systems, we just don’t know what we don’t know. And the limited, often confusing visibility provided on vendor websites doesn’t help in narrowing this information gap.

At Quorum1, we’ve helped countless clients with vendor research, selection, solution architecting, and implementation. Collectively, we’ve led projects across hundreds of systems and platforms and are in a constant stay of learning about new vendor tools and functionality.

And because business systems range depending on industry and use case, we rely on certain principles when making recommendations to our clients. The purpose of this post is to help you make as informed of a decision as possible in the context of bringing on new systems to help your business grow.

As one example, I know of a provider of demographic data such as median household income, population growth, and average rents used by countless real estate investors. I had the chance to trial the service for the first time recently to see what all the hype was about and was shocked to find that the most recent data was from 2018. How could this even be possible? We’ve had a full census since then, and I know of free services that can get me accurate demographic data on 2021. Not to mention that there has been a huge black swan event in the pandemic that renders any real estate demographic data from 2018 utterly useless.

The point is this, to the extent possible, understand where the data is coming from and how often it is refreshed. Further, what is the extent of the features offered? Do they fit your exact use case? Really challenge yourself to identify where the system falls short.

Are you going to need any systems to supplement the one you’re evaluating? As a general principle, in the context of business systems, less is more. Not only is this true from a cost perspective, but from an implementation, upkeep, and management perspective. One more system means one more system you’ll be responsible for managing. More on this later.

We’ll also talk more later on about some specific strategies for digging this information out of company reps and websites.

Customizability is both a blessing and a curse. It is a blessing in the sense that it reduces one-size-fits-all solutions. It can be a curse in the sense that if the platform is infinitely customizable, then it can be, by definition, infinitely complicated. What follows is that the more complicated a platform becomes, the more important your implementation becomes.

Does the program fit your use case right out of the box? If not, what does it need to do in order for it to fit with your use case? Finally, how hard would it be to configure the system to meet your needs?

For example, is it a quick change of the settings or is it a third-party automation? Does the solution require code? Finally, how much time do you have to manage the platform’s customizability?

Think of the edge cases and how you’ll work around them, meaning, think of your most complicated use case and ask yourself if the solution works.

Remember, customizability is a double-edged sword, so manage this carefully!

Let’s take a big step back. Why are you looking to use a technical business system? Presumably it’s to make your life, and perhaps the lives of your employees, easier.

Nothing feels worse than putting in all of this time and effort into research and generating consensus internally to purchase said system only to find that it “doesn’t work”. Equally miserable is investing the time and money into a system only to find tremendous resistance among your employees who are complacent with the processes of today instead of the efficiencies of tomorrow.

There are a few reasons why a system might not work. It could be the case that the service is complicated and no one wants to use it. Maybe the system’s not user friendly.

A system is only as good as the user behind it, meaning, if a user does not know how to leverage the system for maximum output, then the output is suboptimal. This means two things - either we invest a lot of time and money into training our end users on a complicated system or we use less complicated systems.

The latter is much easier to manage, yet, as with all of these other principles, it must be balanced with finding a system that closely matches our use case.

Evaluating a system’s complexity is best done by doing a thorough product demo with one of the company’s reps. Ask yourself the following questions:

A good proxy measure here is literally how many times they’re clicking to find something. If you notice that their voice is being drowned out by incessant clicks, or that they go to click “done” and they repeatedly run into errors saying they forgot required fields, or that the validation rules weren’t fulfilled, it’s usually not a good sign.

Even if you don’t plan to use them now, it’s wise to understand what services the platform does and does not play nicely with. We further recommend exploring exactly what the “integration” entails.

I’ve personally made the mistake of typing in “Vendor 1 integrations with Vendor 2” and taking an affirmative checkmark as the signal to stop my homework, only to find that the integration was so limited that it might as well not have integrated at all.

As an example, I was evaluating two different telemarketing softwares and their integrations with a specific CRM and I was so convinced of the one software’s superiority that I though the testing would be merely a formality. Wow was I wrong. I plugged in the “superior” system and found that while it technically integrated, the integration was so severely lacking that it bordered unusable. I learned the hard way that you really never know about an integration until you plug it in and test it. Again, you just don’t know what you don’t know!

Integrations are by definition a spectrum. There are services that do not integrate, there are limited integrations, such as certain features offering reciprocity or using a third-party automation tool (more on this later), and then there are fully seamless integrations. A checkmark on a product website affirming an integration between services likely falls in the second or third category. But which one makes a world of difference, and it’s up to you as the researcher to dig deeper here.

Anything you build or implement must be managed. Unfortunately, having the service integrated doesn’t mean that you’re done. You then need to perform maintenance whenever it breaks.

If you use a third-party automation service, you now need to manage this additional service in your tech stack. And the question fundamentally is this: Who is going to manage your vendor systems?

Unless you’re using a consultancy or other research provider to help you with your team’s business systems, then perhaps the answer is you? But it’s probably safe to assume that this is something you got dragged into or that you feel compelled to do in the interest of your team and that your real full-time role is something very different.

If you will be responsible for managing this tech stack and it is not your full-time position to do so, then it’s wise to minimize the number of systems, the number of integrations, and most importantly, the complexity. Do not invest time in integrations that do not serve a very real purpose.

Are you going to need to run reports? Or generally be able to quickly and concisely consolidate data and present it? If you don’t know, then it’s wise to be conservative and assume that the answer is yes. Ask the demonstrator to show you some sample reports pulled from their platform.

Mentally count how long it takes for the demonstrator to generate the report. If the reports are performance based, how is the visualization? Are the figures easily understood? Can the reports be exported into CSV, PDF, or another appropriate format for your use case?

What would an executive at your company think if you handed them the report? Would it be ready to present out of the box or would you have to workshop it? If you need to workshop the reports generated, how much time does each one take and how many would you need to do?

These are critical questions to ask because ultimately time is money. And if the systems are going to frustrate you, then it’s all the worse.

If a system works out of the box just fine today, then good! An exceptional system, however, is one that is constantly improving.

Just as there is a spectrum of integration scope, there is a spectrum of how good a company is. What makes a great company a great company? It’s a number of things, to be sure, yet in our opinion one quality stands out above the rest, and that is their dedication to continual innovation.

With business systems vendors, this is readily apparent in the vendor’s roadmap. Some roadmaps are available directly on the company’s website while others are more cagey. See if you can find the roadmap. Are there any key requirements which are noticeably absent? What is the timeline for implementation?

A strong roadmap means the company is ambitious and gets excited about servicing its customers at a higher level. We absolutely love to see strong roadmaps and perpetual innovation!

In this post we’ve covered our principled thinking on how to select the right business systems for you and your team.

Now we’ll cover how to avoid falling into some of the most common traps, namely:

Simply put, the best way to avoid these traps is to get a good product demo and a free trial of the service.

Not just any product demo, but one in which you are highly engaged, asking thoughtful questions, and exploring the edges of your use case. We’re asking ourselves if this solution will work for our least technical user, how we may need to supplement the system, and how it plays with our other systems.

The best way to get the most out of a demo is to be prepared. Have our principles in hand and come with a list of questions. The more time you spend getting ready for the demo, the less questions you’ll forget to ask.

And not just any trial of the service, but one in which we explore every nook and cranny of the system.

Though this is time intensive, it is time incredibly well spent.

Product websites barely scratch the surface on giving the end user a sense of what it is like to be a customer. To be fair, it’s a hard task. It’s like explaining a multidimensional using only two dimensions. With product websites and sales collateral, you are seeing static images of what is inherently a dynamic service.

It goes without saying that these are lessons we’ve learned the hard way. Our hope is that you can learn the easy way and continue optimizing your businesses systems and processes!