November 4, 2019
Every association has unique ways of running its business, so when you’re shopping for a new AMS, it’s tempting to customize it to your needs and preferences. But is AMS customization the best option? No, not when you can configure (modify) software. In our experience, configuration can meet 95 to 100 percent of an association’s requirements.
Customization? Configuration? Are we splitting hairs? Definitely not. Before you start looking for a new AMS, you should understand the difference between the two, the drawbacks to customization, and why configuration is a more sustainable and practical choice.
Traditionally, a customized AMS was designed for you by a developer from scratch or almost from scratch, for example, a customized Access database. But now, many AMS—even those labeled as SaaS (Software as a Service)—are customized, although they may not be identified as such.
Customization involves rewriting the codebase for an association’s specific needs. Sometimes customization is necessary to handle truly unique needs. But customization comes with up-front and recurring costs. You should know about those costs before signing a contract.
What makes it more confusing is the language used by sales teams. They sometimes use the word “configure” when the word “customize” is more accurate. How can you tell if a vendor is talking about customization or configuration? Ask if a developer will have to build the functionality you’re discussing. If the answer is “yes,” it’s not configuration, it’s customization.
Configuration is the modification of software without having to rewrite the codebase. Customizations in one AMS product might be configurations in another. True SaaS products, like MemberSuite, use configuration to meet client needs.
A clue to whether a sales team is talking about configuration is when they say a requirement is “baseline,” meaning, there’s no need to customize the core product (rewrite the codebase). Instead, they can make a configuration to meet the requirement or make no modification at all.
Configuration is used for software that’s flexible enough to meet most (80% on average) market requirements. Any unique needs and complexity—the remaining 20% of requirements—are handled through configuration settings.
During implementation, the AMS professional services team configures your software, but after implementation, anyone on your staff with system administrator permissions can configure it.
Common examples of configuration include:
When an AMS provider rewrites the software’s codebase for the different needs of dozens of clients, you can expect ramifications for everyone.
Longer and More Expensive Implementation
The cost of implementing customized software can be twice as high as the cost of implementing true SaaS. You’re paying for the time of a team of programmers, business analysts, testers, and documentation specialists to design and deliver a new customized version of the codebase for your needs. All this work adds up to a lengthier implementation process.
On the contrary, the implementation of configurable software is less lengthy and expensive since no development time is needed. During implementation, the SaaS vendor’s team is focused on configuration changes and data migration, not software development.
The AMS vendor support team knows their core product inside and out, but they may not be familiar with your customizations. If there’s a bug in your customized version of the software, you’ll be the only client with that problem so it may take longer to resolve. If the bug affects the core codebase, the vendor’s team must fix, test, and patch the bug on dozens of customized versions of the codebase—just hope you’re first in line.
On the other hand, support is more responsive with configurable SaaS software. Since all clients are using the same codebase, a bug affects everyone. It gets fixed immediately and everyone benefits from the improvement.
Off the Upgrade Path
Ask your vendor about the cost to maintain customizations when upgrades are released. This ramification is perhaps the most frustrating aspect of customization because customized code kicks you off the upgrade path. If you want to take advantage of the new features and functionality included in product upgrades, you’ll have to pay the AMS provider or a consultant to rewrite your customized code so upgrades can be applied and tested.
In stark contrast, the vendor of a configurable AMS has built one codebase for all, versus building a customized codebase specifically for every client. This difference allows SaaS vendors to innovate faster and keep up with the demands of the market.
Releases are more frequent—twice a month, in our case, and free. Everyone’s on the same upgrade path and, therefore, everyone’s always on the latest version of the software.
Negative Impact on AMS Vendor’s Business Model
All these customized codebases have consequences for your AMS vendor. With dozens of codebases to manage, it’s too cumbersome or downright impossible to upgrade every client to the same version.
To support all these versions, the company needs a large team of developers, testers, and client support people. The cost to maintain all these codebases is passed along to their clients.
True SaaS AMS will always be less expensive because the vendor can effectively manage their product at a lower cost—and these savings are passed along to you. The clients of true SaaS benefit from economies of scale. Because every client uses the same codebase, the vendor’s staff only has to support one codebase. They’re not passing the costs of dozens of versions onto their clients.
Avoid customization if you can. Prioritize your requirements into “must-haves” and “nice-to-haves.” Talk to your AMS vendor about configuration possibilities. See if you can make a configuration or change a process rather than ask for a customization.
To learn more about the differences between true SaaS AMS and cloud-based AMS, check out our AMS Buyer’s Guide.