Best Practices for Internal Enterprise App Adoption



Close Banner

Free Template & Financial Spreadsheet

Create your SaaS business plan

Sign Up

Building an internal application for your team seems straightforward, at first. Your user base is guaranteed, right? Sadly, internal app adoption isn’t that simple. Sometimes employees struggle to use or refuse to use the tools you provide.

A poorly designed tool could frustrate your team. A single employee’s dissatisfaction could poison others who would be otherwise satisfied. If your team fails to adopt the tool willingly, you could lose whatever you spent to purchase or develop the app. If you have to force them to comply, you could damage your team culture.

On average, employees use about eight business-related apps at work. Convincing them to pick up another is often challenging, which explains why 63% of managers say the pace of establishing new technology is too slow.

If you want to encourage adoption of an internal app, you need a plan that makes your team want to use the new tool. These best practices will help.

Step 1: Get Buy in From All Levels

Before you push a new app on your team, you’ll want to create allies within your organization. This is especially important if you have multiple layers of management or if the team is so big that you can’t personally evangelize the app to every person.

Let’s say you’re a Vice President of Marketing who reports to the CMO and you want your marketing team to switch to a new customer relationship management tool (CRM). Instead of sending an email to the entire department instructing them to switch, you should first introduce the tool to the heads of each team - sales, customer success, content, events, etc.

Explain the benefits to each team leader and help them understand why you want everyone to adopt the new tool. If the switch is mandatory, say so, but make sure to lay out the positives so they can relay that information to their subordinates.

Once you turn each team leader into an ally, they can spread your message. Each team member will be more likely to switch if the change comes from someone they know well (their immediate team leader, as opposed to the marketing VP they rarely speak to).

Step 2: Build for the Stakeholders

“Stakeholders” is a nebulous term that often only applies to people who have a financial interest in an app’s success. For an internal app, however, it also applies to an app’s primary users who will derive the most use from it.

For example, a human resources application designed to manage payroll, paid time off, and other benefits would primarily affect the HR team. They would use it every day to manage their workload. Other employees, however, may only use the app once or twice a year to check pay stubs, request time off, or update information.

In this case, the HR team members are stakeholders who should be considered when you choose or build the app. That isn’t to say you should ignore other employees, but the HR team’s needs should take precedence.

If you aren’t sure whose needs are more important, use a power-interest matrix. This will help you identify your stakeholders. Map your team members (or team role, like “accounts payable supervisor”) into each quadrant. Design your software for those who fall into the high interest / high power category.

Internal app adoption

Step 3: Emphasize the Familiar

Adoption rates are always better when apps are intuitive. How do you achieve intuitiveness? By designing your app in a way that’s familiar to the user. Match features, interfaces, and workflows to other apps they already understand. Put buttons, objects, links, and data where users expect them to be.

For instance, let’s say you want to include a comment feed in your app. There’s no need to reinvent the wheel here. Use the same standard, nested comment feed layout that appears all over the web so users can interact with it immediately without consulting a help doc.

Step 4: Don’t Change the Job

People rarely appreciate dramatic changes to the nature of their job. If your new app drastically changes how they work or what they work on, you’re likely to see some resistance.

For example, let’s say you implement a new tool to monitor your employee’s time. It requires them to clock-in through an app and log their activities. If they aren’t used to this requirement (perhaps you never monitored their time before), they’re probably going to resist using the app. They’ll neglect your trainings, make careless mistakes, or possibly refuse to log in.

Does this mean you should never make radical changes to someone’s job? Of course not. Sometimes you have to take big steps in the interest of the organization. Just be prepared for adoption resistance.

Step 5: Use the Tool Yourself

You can’t ask others to adopt a new tool if you won’t use it yourself. The best way a leader can create change within an organization is to set an example.

Make sure you have one of the first accounts in the new app. Flesh out your profile (add a current avatar, fill out your contact details, or whatever else it entails) and be active (send invites and connections, add integrations, etc.).

Most importantly, learn how to use the app better than anyone else. Understand its features and workflow. If someone asks you a question about using the app, you should know the answer or how to find it.

Step 6: Create a Roll-Out Schedule

It’s poor practice to drop a new software tool on your team and tell them to abandon their old system in favor of the new one today. That creates too much disruption. Not only will you upset your team, you could also compromise the effectiveness of their work.

Imagine, for example, that you ask the marketing team to use a new automation tool while they’re in the middle of an important campaign. They designed and launched the campaign using the old tool. Switching to the new one at the last minute would disrupt the campaign (possibly ruining it) and create frustration in your team.

Create a roll-out plan that eases your team into the new tool with a non-disruptive schedule. This plan should include:

  • Key dates - When should employees begin to adopt the new technology? Will you deploy it to everyone at the same time or on a schedule to different groups? When should they complete adoption? When will you cancel or turn off the current solution?

  • Training opportunities - Will you host training sessions? When will they happen and how will they work? Are they mandatory? Will any resources (articles, video, screenshots, etc.) be available in perpetuity?

  • Your expectations - What happens if employees refuse or fail to adopt the new tool on time? Are there any incentives for adopting it quickly?

Try to keep your roll-out schedule flexible to account for situations like our example above. If a person or team has a legitimate reason to delay adoption, give them some leeway.

Step 7: Get Their Feedback

As your team begins to adopt the new app, solicit their feedback. Ask penetrating questions about their new workflow and the app’s effectiveness. Make it clear that you aren’t just concerned about the app’s success, but you also care about their happiness.

If possible, do what you can to address your team’s concerns, even if that means altering the app for their needs. Keep in mind that the people who use the tool every day are more likely to find bugs or opportunities for optimization. Don’t discount their suggestions.

If you can’t change the app, look for other ways to meet their needs. You might install a plugin or write a script to automate something. You should also address your team’s concerns in your training so future employees know the workaround.

Going Forward

New tools for your organization can streamline productivity and enhance efficiency, but only if your team members adopt them. These best practices will help you boost adoption so you can enjoy the benefits of your new app.

Close Banner

Building a product?

Discover the DevSquad Difference

Learn More