There is a level of user monitoring that we can use for different industries, different team sizes, and different businesses. When we have created the tools and carried out the implementation process, we’ve gone through change management and seen how the team adapts to the tools. We now want to monitor, in real time, how they’re interacting with them, whether they are using them, and the problems they are running into. Now, remember, these are internal tools. And even if they’re not completely internal, they’re still primarily internal, with a few external users allowed. These are not public software products. There is a certain level of monitoring that we can do that is acceptable in particular industries or for different teams.
I worked on customer apps for a wellness platform that had confidential or very private information. We weren’t able to look at that information or monitor it directly as people used it. Instead, we looked at user behavior, clicks, and where they were having problems. We relied more on user feedback and the behaviors that we noticed. Let’s say we have an event. We want to know how many people are clicking to schedule. In this situation, for this business, we have wellness practitioners who are working with clients. So if they are sending materials or resources to their clients, we want to see how many of those clients access those resources. We want to see how many of them created or updated their passwords, how many joined the newsletter, how many joined the practice library, how many opened the emails, how many accessed the platform, and when they last signed in to the tool. So these are the levels that we can monitor.
If it’s something more open, with external users, contractors, vendors, people who are purchasing, or visitors who are just coming in to view, we have more flexibility in how we monitor them. We also have certain terms and privacy considerations that we make sure to address with users before they come on board. We want to see how the tool is being used. We want to see the problems they’re facing. As much as we encourage transparency across all of these things, most of the time, users are not always going to tell us when they run into problems. So we want them to tell us. We want to observe. We want to understand how they experience the tool. Even before we start, before we create or go into the process of implementation or building, we’ve already done our initial assessment. We looked at the requirements. We looked at the priorities. We looked at all the factors that we needed to consider before building or creating these tools. What were the complaints about the previous tools? How are we going to avoid them? What do we need to do differently?
Now we’ve taken all of that into consideration. We have our user journeys. We have our user roles. We have our role-based access permissions. We know who is going to do what, where, what access they have, what level of access they should have, what they should be able to touch, what they shouldn’t see, and what their experience should be like. We also clarified all of this with different people on the team to make sure it was the best possible approach. But remember that, as much as we try to get into the minds of the users when we’re creating these tools, users are always going to develop their own behaviors. So we want to monitor those behaviors, understand them, adapt to them, and make revisions where necessary.