It’s pretty common for prospective clients to ask software vendors for references prior to signing a contract. A 15-minute phone call with two or three organizations who have used the system extensively and sampled the vendor’s services can help mitigate the risk - and reduce the anxiety - related to acquiring a new system.
If you’re evaluating new applications such as a learning management system (LMS), you may be considering asking the shortlisted vendors for references. Here’s what you should know:
- When you applied for a job and the prospective employer asked for references, did you give them the names and contact information of people who like you or your arch enemies? If you got the job, likely the former. Similarly, vendors provide prospective customers with the contact information of happy clients. So, asking a reference whether they are happy will almost surely generate a "yes." That doesn't mean contacting the reference is a waste of time, though. You can still get some good information from the process.
- References may gush about how great the software is but you need to be aware that your future use of the system may be pretty different from how the happy client uses it. Consequently, it often makes more sense to ask references questions that aren’t related to the features of the platform. Relevant questions may touch upon the responsiveness of technical support, any unexpected uptime disruptions, how often the vendor makes updates to the system, cost increases upon renewal, etc.
- Knowing that the reference organizations may use the software differently, some prospective clients ask the vendor to provide them with references that closely match what they are planning to do.
Can you put us in touch with a client in the healthcare industry selling virtual instructor-led courses in multiple currencies?
Regrettably, that's easier said than done.
Here’s why: Client privacy.
Vendors may not know exactly how each of their clients is using the system. This isn’t because they don’t care. Rather, it’s in respect for the client’s privacy. For instance, here at Absorb, our terms and conditions specify we can only access our clients’ data in two ways:
- In aggregate with the data of other clients, to improve the system. An example might be for us to evaluate how many times per hour a certain type of report is accessed. The result of this analysis would be used to optimize this report.
- To provide technical support. An example would be that a client contacts our support team and says that one of their courses isn't behaving as expected. The support technician may then ask permission to enter the portal and look at the course configuration.
The account executives involved in the sales process don't have the ability to visit various portals to see how clients are using the system. That is a breach of security. In fact, when an organization becomes an Absorb LMS client, the only people with access to the portal are the implementation project manager, client manager, and support team members.
Even if we know of a client using the system as you describe, we cannot simply pass on their contact information. Again, this would be in breach of our privacy policies. Consequently, we need to track down the right person, contact them, and obtain their permission to share their contact information. Unfortunately, some organizations have a policy banning employees from acting as references for the software they use. They do this for various reasons:
- They don't want competitors to know what software they use.
- They don't want happy references to impact the organization's ability to negotiate with the vendor.
- Etc.
Vendors often make sandbox accounts available to potential clients to make it easy for them to test the system themselves. Rather than speaking to a reference about whether the LMS does something, it can often be easier and quicker to simply test your own use case.
Want to get started in your own Absorb LMS sandbox? Sign up for a demo portal and a member of our team will help you get going.
