Preparing for the Purchasing Questions of Your Buyer Group
How to win consensus and influence stakeholders in three purchase scenarios.
Your Ultimate Guide to Preparing for Learning Management System Purchasing Questions of Your Buyer Group
There are a large number of steps involved in buying any enterprise software, and learning management systems (LMS) can gain a lot of internal interest given the impact they have on everyone’s training and development. But with more eyeballs on the purchase comes more scrutiny, and more questions from within.
How you answer these questions depends on a few factors. Throughout this article we’ll explore those, but especially:
- How are purchases made? By committee? With consensus? Independently?
- What role type does the person asking the question have?
Read on to find out how to prepare and effectively answer the purchasing questions for your buyer group when seeking an LMS solution.
How are purchases made at your organisation?
There are three common ways an LMS purchase can be made:
- Committee: An approved select group of representatives who usually hold veto power on large-sum contracts. (The high-level scenario.)
- Consensus: Shared power by everyone who is fundamentally affected by a decision (in this case, a B2B software purchase) to find the right solution. (The win-win scenario.)
- Independent: Questions come from your immediate team members. (The everyone gets a say scenario.)
Each scenario has its nuances, though ultimately will be unique to your organisation. However, there are a number of recurring questions we have seen or heard arise in the businesses we’ve worked with—and a few we’ve even found to ask of your buyer group that can help assuage their concerns.
The Committee Scenario
Out of these three scenarios, the committee scenario is known as the most complex and usually comes with the most questions to prepare for. This is the scenario where your purchase decision is put in front of a procurement group, leadership team or sometimes a technology oversight committee.
In the case of buying software, it’s rare for just one person to authorise a choice. While up to a dozen people can have influence, a committee of less than 10 has the decision-making power. Purchase or procurement committees are groups established to review and evaluate recommendations for purchase, with the ultimate responsibility for a successful outcome for the process. Most often, committees are used for large, highly valued contracts—so, they’re likely under as much pressure as you, as the recommender, to ensure that all bases are covered.
It will vary between organisations, but you may find yourself answering to representatives of the Finance and IT/Technology departments. Logistics managers, general counsel and directors may hold a seat too, so to speak. They may take into account previous initiatives or software purchased, business drivers and goals, and budget constraints. With this in mind, let’s dive into tackling some of their questions.
Answering the committee’s questions
Allow for extra questions during this scenario than others, given it can take if not weeks but sometimes months to gain approval from a committee. Questions you should prepare for in advance to proactively get your selected LMS over the line in a timely manner are:
Do you have a business case carefully thought out and documented?
One universal reason for purchasing LMS software is as part of a digital transformation strategy. At this early stage, you’ll need to create a strong business case that outlines:
- Selection criteria: The non-negotiable features and functionality.
- Cost: Including initial outlay, time to impact, learning curves.
- Schedule: Meaning implementation period.
- Business benefits: Including impact on business drivers and day-to-day processes, retention, recruitment and, ultimately, ROI.
- Risk assessment: Or how you might mitigate issues such as low engagement, poor user experience and potential loss of deposit.
- Strategic business alignment: Where the initiative falls in line with roadmaps, business goals and/or any business functions.
This is your chance to break down the investments required of and benefits for each targeted business units in your organisation. Harmonising the different elements will make clear the most crucial aspects of the initiative. You’ll want to bring everything back to a needs or skills analysis (aka the first step of even thinking about purchasing software). No software can do absolutely everything you want, but a business case will go a long way proving the value created by the solution you do choose.
What are the associated business risks with moving forward with this purchase?
We mentioned risk assessment above, but it will undoubtedly be worth its own question in the committee’s eyes. Identifying the potential challenges is time and money well spent in software procurement, and will more than pay off when you can answer all of the committee’s questions.
Low usage, over and underuse of resources, buying outside the scope of selection criteria or even market risks are all potential scenarios that can lead to value leakage. It’ll pay to not only define these business risks for the buyer group, but to showcase the plans you have to mitigate them in the case they may arise.
If we are changing providers, what are the transition and change management plans that have been put in place?
Avoid being put on the spot with this question and create your change management plan before meeting with your buyer group. This is best done after a needs analysis, so you are aware of what stakeholders want or are expecting from the change. An example of a comprehensive plan would include:
- Define your goals. Clearly outline where you are and where you want to be as the outcomes for the plan, such as how the new software will impact the business, employees and your customers. This will create value for stakeholders, and can be used as part of an awareness campaign to generate buy-in. Define your KPIs while you’re at it (this will go a long way towards getting committee sign-off).
- Create a team consisting of a change manager and key stakeholders who are responsible for overseeing the stages of the plan. Ensure each role is assigned to a relevant stage, so you can best utilise any resources needed and prevent delays.
- Document the scope. Plot a timeline, including that awareness campaign, note all the personnel that will need to be drafted and when, and outline the amount of resources and cost to budget that will be required. Plan for resistance here too, and create a problem-solving matrix that employees and stakeholders alike can refer to.
- Reinforce change. Demonstrate how you’ll ensure resistance doesn’t return; leverage subject matter experts who can be points of reference during these times, such as your Chief People Officer. Iterate the plan every so often, or when an unexpected hurdle arises. It’s important to also include plans for positive reinforcement to encourage more willing acceptance of change.
Is there a detailed overview of privacy, data and security protocols?
While this can only truly be answered for a solution when final contenders are in the mix, you can prepare your own non-negotiable security requirements.
Firstly, outline the security standards that are currently utilised in your organisation. This can be everything from firewalls to industry regulations. Lean on your IT department to get clarity on factors:
- Functional requirements. Things like access controls, authentication (i.e. username and password credentials) and authorisation (user privileges). Keep in mind how strict you currently are on password quality, recovery, and changes and multi-factor authentication.
- High risk functionality. Think uploads and downloads, access by contractors/consultants, and how sensitive data is stored. What are the functions of business that require data transfers? What are the vulnerable processes?
- Testing environments. Any software worth its salt will be rigorously updated with new developments on the vendor’s timeline. Sandbox environments are important for cybersecurity, because they ensure that potentially malicious code can be safely tested—in a replica server—with no disruptions to your actual software.
Something else to consider when creating a detailed overview is to anticipate the follow up questions the committee may have. When designing requirements with your IT specialists, ask yourself:
- Are our requirements ambiguous? Could something be misinterpreted?
- Are they consistent with our security measures across the board? Or do they need to be stricter?
- How are we measuring the effectiveness of protocols?
- Can we actually test all requirements? As in, are they specific enough to be tested, measured and quantified?
- Have we included room to evolve these requirements in future?
Want to see Acorn PLMS in action?
Hit the book a free demo button here, take seconds to fill in your details, and find out how Acorn can help you succeed.
The Consensus Scenario
Building consensus is most difficult in the early stages of buying. Research has shown that the biggest obstacle to consensus is on the type of solution to acquire, followed closely by defining the actual problem to solve. The more people involved in that process, the lower the chance of actually reaching a consensus at all.
And when it comes to making a B2B purchase for a learning management system, the consensus scenario sees multiple people involved from multiple business departments. All of whom need to agree. Each stakeholder will likely have similar questions to those that a committee may have, but you work closer together and can answer them much quicker. For this scenario, you need to understand what the common thread is.
Building consensus with a common thread
Consensus decision making is about finding a solution that everyone can support. By finding the common thread between all stakeholders, you’ll be able to get consensus. And to find consensus, you need to ask—and understand—what the business goals are that they are all aligned in achieving, whether they lead commercial, operations, HR, finance, or any other key business function.
Think about it less as trying to win people over and more a collaborative problem-solving exercise. In that case, let’s discuss a couple of the key questions your stakeholders may ask:
- How will this new software help us manage business drivers?
- What existing processes and technology can this software complement?
Learning isn’t a business pain for us. How will this software help us manage our business drivers?
Defining a problem stakeholders face (shared or otherwise) will go a long way towards proving the merit of a solution—as well as showing the value of online learning. By probing this angle, we can:
- Find a shared pain point. Operations and Sales may not think they have much in common on paper, but they may see overlap in challenges such as lacking skillsets, poor compliance or high turnover.
- Create a common language. Change initiatives come with a level of ambiguity that can impede progress. A shared vocabulary that defines goals, culture and expectations will underpin your organisation’s success.
Let’s talk about Ops and Sales. Operations needs to ensure the business is running as efficiently as possible. They’ll likely need to be up to date with compliance, aware of business goals and have enough staff to keep up. Sales, again, will need to know the latest business updates to services or products, be clear on organisational messaging and have enough people to meet customer demand. The clear shared pain is having the right number of people, but when you break it down, both functions also need people with:
- The right skillsets and knowledge
- A solid understanding of the organisation’s mission.
So, the common problem is ensuring your organisation has the right number of people, with the right skills, in the areas you need. Where to next?
What processes will the software support and will we have to displace existing software for it?
It’s possible that some resistance to a new product could come from digital fatigue. On the plus side (and to your advantage): Integrations between different workplace software are becoming more and more popular, not least of all because they help businesses get the most out of multiple systems while streamlining the user experience. So, what you’re going to want to do here is reframe their question as, “What’s it worth to you to cut the tedious processes in your day by half?”
There may be a number of platforms your stakeholders utilise independently, including:
- Time tracking
- Project planners
- Calendars, e.g., iCal or Outlook
- Collaboration and messaging apps
- Customer relationship management.
These needn’t be displaced, nor would the capacity to implement new software be a massive burden. Consider Single Sign On; employees can securely use the same login credentials for a new LMS that they do for current internal systems. They can pull learning activities into their desktop or email calendars, so they can align it with work duties. They can even integrate their chat platforms, like Microsoft Teams, with learning management software and access coursework in the Teams app.
On the other side of the coin, the power of automation benefits administrators and managers, too. The ability to set and forget compliance courses and repetitive or low-value tasks like data collection, approvals, updates and sending reminders and notifications can free up to 30% of an employee’s time. Considering that’s somewhere around $13,000 per year, per employee, the business and day-to-day benefits of integration and automation cannot be understated.
The Independent Scenario
In the independent scenario, you’ll find the questions come from your immediate team members. This is where a purchase decision is made from within one single department. For learning management systems, this is typically HR.
Questions to prepare for here include:
- Transition management off a legacy platform
- Project team, who is responsible for what and the time investment
- Functional requirements
- Features on the provider’s roadmap.
Keeping in mind we’ve already covered some of these topics, let’s dive into answering some of the questions you may face from your teammates.
Answering questions based on roles
There are three roles in this group: Users, influencers and buyers. They’ll each have their own concerns:
- Users are the ones actually using the product, meaning they’ll be invested in the performance of the product.
- Influencers are your tech specialists who evaluate product specifications. They’ll also be crucial to determining the sustainability of the product.
- Buyers negotiate the terms of purchase with the aim of a frictionless buying experience.
Users: Is this easier to use than our current platform or platforms?
We’re in the end user era of software. In this time, those who directly and regularly engage with software have the power to suggest and kill an initiative before it begins. The influence they hold over buying decisions comes down to product feedback; they’ll be invested in user experience (UX) and the impact it’ll have on their job performance.
At the crux of it, your users want something that’s easy to use or trying to navigate. So, we need to solve that problem for them. The key is to get into the weeds of this group and:
- Conduct employee surveys to get a better median understanding of what is important to individuals when using new software. Ask about legacy software they already use in the workplace, as well as any software products they may have actively purchased and implemented outside of work. What features did they like? What don’t they use? What would they have asked a provider in hindsight? What would make them more likely to utilise a new workplace software product?
- Seek out a chief representative (perhaps a department head, business owner or line manager) whose team will be impact be the solution. They’ll either be using the system too, or have a clearer idea of the desired outcomes for their people past what will inspire uptake. Ask them what outcomes they would want for their team in terms of skills gained and business outcomes affected, for example.
Influencers: How does this help me and my teammates do our jobs?
Your influencers are likely tech personnel or mid-level managers who are responsible for administrating the system from within a team. At this level, they’re also the people they will stand up for the solution against push-back, making them important for change and transition management, too.
We want to make influencers advocates for a solution, so we need them to believe the solution will:
- Make their jobs easier (i.e., alleviate pain points, make them more productive, more engaging, more efficient)
- Offer them professional growth paid for by their employer
- Fortify their role as positive change agent within their team
- Give them added innovative value as an employee
- Not block or threaten their role.
In order to address these points, we need to talk to them about product specifications and roadmaps. This is most effectively done with a feasibility review to compare products, completed with your influencers’ input. Below is an example of how potential concerns can be translated into a requirement in a feasibility study, or even a request for proposal (RFP). Feel free to customise these as fit your organisation in our downloadable feasibility study spreadsheet.
Buyers: How can I make this buying process as easy as possible?
At the last stage of the process are buyers, who are after one particular thing: An easy buying journey. B2B software purchases are often complex, and the buyer is on the hook for any stuff ups. If users are judge, influencers are jury, your buyers are executioner, with the power to nix a project. This is because they are likely responsible for budget and resource allocation in the team—which makes them the ultimate decision maker in the independent scenario. They don’t have time to worry about the nuances of industry, they need the straight facts that will help serve as a process.
So, let’s flip the question and ask what a pathway to buying success looks like. Consider:
- What potential problems or blockers can they identify that may arise? What are the consequences of inaction or delayed deadlines?
- What information do they need upfront in order to make the process as seamless as possible?
- Whose help will they need and at which stages?
- What expectations do they have about trials before purchase?
- What expectations do they have post-purchase? Will they need to be involved in implementation plans?
- Who are the providers?
Using this criterion, we can break the buying process into three key sections: People, process and paperwork.
- Define project roles. The buyer may need sign off from executives, or further information from mid-level employees. They may need to coordinate with other departments, such as Finance, IT or Procurement. At this stage, we want to account for conflicting schedules of the people involved.
- Build out a timeline. Problem identification is important here, as it will help to counter loss aversion. Note the points at which a necessary request may be denied, and identify solutions or a remapped course of action.
- Prepare documentation. It’s not necessarily paperwork in the traditional sense, but the creation and delivery of requests for proposal or information and any receipts or invoices that will need to go to Finance need to be included in the timeline.
Closing remarks
Answering the questions of your buyer group is never an easy process, owing to the complicated nature of buying enterprise software. The learning management system is no different since it is bound to impact every role in your organisation in one way or another.
You may find questions coming from a few different groupings:
- The committee, who are carefully selected representatives overseeing a high-value contract.
- The consensus scenario, whereby a group of stakeholders share decision making power.
- The independent scenario, when questions come from your immediate team.
Your best plan of action is to prepare before you go in to present a possible solution. Consider the pain points your audience has, the business concerns they’ll want addressed, any issues with usability. The questions will depend on the audience and their but regardless, answering their questions by addressing their concern—rather than spruiking the product—will go a long way to towards building consensus on an LMS software solution.