3 Foolproof Steps to Ace Your Wrike Implementation

Back in February, Wrike's customer success team launched a "churn analysis" campaign. For two months, we collected feedback from customers who had decided to stop using Wrike and tried to identify their reasons for leaving.

While there were many different reasons why people left Wrike, such as a lack of financial resources and specific missing features, "lack of usage" ranked at the very top, far surpassing all the other factors.

To be honest, at first, I didn't think this campaign was very helpful. Deep in my mind, I kind of knew the top result would be "lack of usage," even before we started. What I didn't know was why people stopped using Wrike or the reasons behind their "lack of usage."

Nor did many Wrike customers know why themselves. When we talked on the phone, they would say, "I don't know, I guess we just weren't ready for a tool like this," or "I don't know, it's a good tool, we just stopped using it."

It was frustrating because I knew they came to Wrike for a good reason, whether it was to eliminate a pain point or to improve a process. Something must've gone wrong in their implementation and adoption of the platform, and it was my job to figure out what happened. 

Analyzing the churn campaign results

At first, I assumed there simply wasn't enough authority coming down from management to make the use of Wrike absolutely mandatory — as if flexing muscle at the team members would help solve their adoption problem. But soon, I found that wasn't really the case. Most of the time, team members seemed to be in as much pain as the authority figures and power users (the person in your company who knows Wrike the best and will likely be responsible for training) — everyone was sick of the old way of managing projects, i.e., relying on emails and Excel spreadsheets. 

Then I started blaming our product. I would tell myself, "Maybe Wrike just isn't built for a certain industry or a certain type of customer." But the data told me that was also not true: for every customer that failed, I could always find another one in the same industry that was very successful with Wrike. 

So what was the problem? 

Why implementation and onboarding fails

One pattern I've noticed during my onboarding of customers was that the people that are more organized in their approach to Wrike adoption (e.g., those with a clear plan for training their team members, emphasizing specific features during training, etc.) tend to be the most successful. On the other side of the coin, people who are less meticulous in their adoption (i.e., they ask the team members to attend a general webinar and then just wave them on to "start putting their projects in there") tend to be the customers who fail right from the start. 

It's a little ironic. If my assessment is true, it seems like the people who are already organized and proactive without a tool are the people who use Wrike the best and get the most out of Wrike. And the people who really need the most help managing their projects and workflows tend to be those least likely to successfully reap the benefits of Wrike. The great become greater, and the disorganized stay disorganized.

The problem: Magic pill mentality 

Magic pills make fantastic stories, whether it's the fitness program that gives you a six-pack in three weeks or the collaboration software that will instantly solve all your team's communication and project management issues. But we all know (even if we don't want to admit it) that magic pills don't work on their own. They are the means to an end, not the end itself. Wrike will help you and your team get more organized -- once you've put in the effort to get there.

The efforts also need to be channeled in the right direction. When working with customers, I've noticed one underlying theme: 

Customers who fail at implementing Wrike do not fail at learning Wrike's features; they fail to be goal-oriented and process-oriented during their implementation. 

One implication of this finding is that my job as the customer success manager should focus not on teaching customers Wrike's features but on helping them be more goal- and process-oriented. 

The solution: 3 clear steps

Here are three things I try to get my customers to focus on:

Step 1. Have a clear goal for using Wrike

One question I always ask customers when I talk to them is, "What's your goal in using Wrike?"

Answers vary:
"Project management."
"Uhh, to keep track of our projects."
"You know, just to have everything in one place." 

Yes, these are all good answers, but they are way too vague, and they lead to unmet goals. 

What exactly do you mean when you say you want to "manage your projects"? Is it to cut down on the amount of overdue work? If so, by how much? How will you know whether you've succeeded? 

Is your goal to provide more visibility into your project's progress? If so, how? Does it mean you can get a quick snapshot of how many tasks are completed by project? By person? By department? 

Sometimes it's hard to ask yourself these questions because you don't really know what you want. 

Or maybe sometimes, you just want to achieve too much at once. Too often, I've seen customers panic because they have not taken advantage of every feature in Wrike, whether it's time tracking, the Gantt chart, the Workload View, or email integration. And before they know it, they start to come up with many different additional "goals" they didn't necessarily have when they first purchased Wrike: track team members' workloads, generate reports for management, run time reports for hours worked, etc. 

It's understandable that these additional goals creep in. After all, you want to get your money's worth, and these are all good objectives to achieve. But you also need to be reminded what your initial goal was because it's only after knowing your goal that you can ensure you feel accomplished. And then, we on the Customer Success team can help.

Step 2. Create a Standard Operating Procedure (SOP)

Let's suppose your goal is to identify overdue projects and tasks and reschedule them when they are overdue.

Once this goal is identified, you now need to create an entire workflow around it so that you can catch your tasks before they fall through the cracks. Here are some questions to ask yourself:

Should you use Dashboard widgets to monitor overdue tasks you've assigned to others? Or should you use email notifications? 

Once you pick your antidote (or even if you pick both), you still need to standardize the process to make sure it's consistent among your team members: 

If you use Dashboard widgets: Which "overdue" Dashboard widgets do you set up? How are the tasks within being sorted?

If you use email notifications: Which projects or tasks do you follow to make sure you get the right notifications? How should you customize your email notification settings? 

Once you've caught your overdue tasks, decide how you will make sure the assignees are aware that their tasks are overdue and that they will reschedule accordingly.

Should you use the "Request status update" feature built into tasks? If so, you have to standardize the process to make sure team members check these request emails instead of just assuming that they will.

Should you use @mentioning? If so, you need to standardize the usage of the notification center for @mentions. Make it clear that "when your task is overdue, you will be @mentioned and responsible for rescheduling the task," so your team members have clear expectations right from the start. 

This might seem like a lot to consider — and we haven't even touched on how projects should be created, how they are to be archived (for reporting), and the approval process behind the rescheduling of overdue tasks. But if you take the time in the beginning, it will pay off in the end, and you will achieve your Wrike goals.

Standardization and consistency are key.

In order to set up the right process, the power user not only needs to know about Wrike's features, they also need to walk in the shoes of their team members. In a collaborative project management solution like Wrike, what each person sees is always going to be different. If you have multiple teams using Wrike, you may need to create multiple SOPs. 

One other thing you've probably discovered is Wrike's flexibility. There are usually multiple ways to do one thing, whether it's receiving updates, denoting important tasks, or assigning work. But whichever way you choose, make sure everyone sticks by the same process. While Wrike's flexibility is a good thing for your team, it also means it does not come with a specific process carved out. You have to carefully build out your own process and communicate it clearly to meet your goals. 

And if you don't standardize your process of using Wrike? Many of our customers who leave Wrike struggle with people who just start to "do their own thing." John creates a custom status folder for tasks that are pending approval, while Amy uses the default "deferred" status for the same type of tasks. Michael schedules his task due dates as milestones, while most of Ashley's tasks are backlogged. 

It's easy to see how things can spiral out of control this way if you let your team members run away with Wrike.

Hopefully, at this point, I've convinced you of the importance of creating a standard operating procedure for how your team needs to use Wrike. Once the SOP is in place, there's only one thing left to do.

Step 3. Conduct your team training based on the SOP

The heavy lifting was all completed in the SOP creation! Now it's just a matter of demonstrating the steps laid out in the SOP to your team, whether via a conference call and a screenshare or gathering everyone in the same room for a live demo. During your training, resist the temptation of going through unnecessary features that the team won't be using; keep it simple and straight-forward. The easier it is for your team to learn the platform, the more likely they will be receptive to using it. 

How to create your own SOP

Now, let's focus our energy on the actual creation of the SOP. There are so many questions you could potentially ask yourself when creating your SOP, how do you know what to focus on? How do you keep yourself from being overwhelmed in the process? 

It's important for you to remember our first point: 

A good SOP helps make sure your initial goal is achieved. 

In other words, the only questions worth considering when constructing your SOP are the ones that truly affect your goals. For example, if your goal of using Wrike is to make sure overdue tasks don't fall through the cracks, then you don't need to come up with rules on how the time tracking feature needs to be used.

Again, keep it simple and pragmatic. It will make managing your process easier. 

Questions to ask when making your Wrike SOP 

No two teams will have the same SOPs for their Wrike usage. Depending on your workflow, you'll likely need to address some of the questions listed here. I've divided them into four different categories: 

1. Starting a new project
• Who is in charge of creating a new project/the tasks inside a new project?
• Are new projects created from a template?
• Once the new project gets created, in which folder does it reside? How are the projects categorized?
• For every project created, what type of tasks need to be created? Are there any milestones that must be included for every project?
• Are there any specific naming conventions for your projects?
• How are the tasks in the project scheduled? Are there any rules or approval processes for task rescheduling? 

2. Task assignments
• Does every task within a project need to be assigned? (This is tied to how tasks are being updated.)
• Who is in charge of assigning the tasks within a project?
• With tasks assigned to multiple team members, should subtasks be used? If no, how do individuals know it is their turn to take action?

3. Updating tasks
• What kind of updates need to be made within Wrike (vs. kept out of Wrike)?
• How are team members expected to communicate their task updates? Should @mentioning be used?
• How are team members expected to find out about these updates?
• How are team members expected to find out about tasks that are coming up or going overdue?
• Should a standardizedDashboard be created and shared amongst the team?
• How should overdue tasks be dealt with? Is there an approvals process for rescheduling these tasks?

4. Completing a project
• How do we determine whether a project has been considered "complete"?
• Where do completed projects reside?
• How should these completed projects be categorized for easy reference in the future?

To make these questions more relatable, I'm including a sample SOP I created for a marketing agency some time ago.

Download the sample Standard Operating Procedure.

Their goal for using Wrike was to have visibility into the progress of their projects and ultimately prevent tasks from falling through the cracks. They also had a simple workflow where projects were created from a template, assigned to project managers, and updated when tasks were completed. Depending on your team's workflow, your SOP will look marginally to vastly different from the sample I've provided.

A new tool will not magically solve all your problems. To make Wrike successful for your team, you must put in the work to set it up the right way. However, once you put a clear goal in place, thoroughly map out your team's process, and create a great SOP, your team will be much more successful in its adoption of Wrike. One month from your successful tool rollout, you'll look back and wonder how you ever managed all your work with spreadsheets and email alone!

What's next? Check out our help center to get your team onboard with Wrike.