Not too long ago I read a Tweet by Ed Gonzales (@PoweredbyEdg) encouraging people to ‘share their story’. My immediate thought was “Nah, I’m light years behind what others post these days”. The post was referencing another by Saron (@saronyitbarek) that said “If you’re holding back on writing that blog post because it’s “too basic” or “too simple”, stop holding back.
Since 2011 I’ve been a part of and active within of the “CRMUG” (CRM User Group) and also within the social platforms Twitter and LinkedIn. Early on I did some presentations and participate in panel discussions which ultimately led to more active volunteer roles within the user group. Doing so lead to many, many incredible connections. People I’d meet in the halls or sessions of Microsoft’s Convergence conference or connect with on calls sharing experiences. Many of those people I now consider friends and am in contact still to this day. I also learned a great deal, both from sharing my own story and having it resonate with others (validation of my own experiences) and in the form of engaging in conversations that re-framed my position on a topic or feature, and learning how to use aspects of things I didn’t understand before.
Let me simplify that paragraph – I learned a lot because I shared a lot.
The irony here was that I have always felt as though I was sharing simplistic/basic content, but it seemed to resonate with some of the people who attended. I have always framed it as ‘this is my experience. I’m not the expert, I’m learning too. But here is what I’ve learned so far’.
Interestingly enough, about a year ago I had been thinking about starting to blog (or, perhaps someday, vlog – what?!). I even brainstormed a list of topics I could write about. After much reflection I ultimately decided that it was of limited value. There is SO MUCH content already out there and it’s all really good. I’m not sure anyone would benefit, I convinced myself. I packed up my brainstorm, tucked it away in a sub-tab of OneNote and moved on with life.
Ed and Saron’s Tweet inspired me to think again. I dug out that list and started to think about it more, and came to a realization. This WAS valuable information to the right audience. “Maybe I should just give this a shot”, I thought.
What Am I Doing?
I plan to post instructional content – application specific “click here, enter this, do that” tutorials. However the bulk of my content will focus on things we need to think about in our role of administrators. It can be an overwhelming world to be a part of! With the rapid development of features, functions and integrations with, well, everything, it can be daunting. It’s no secret that Microsoft produces at a fantastical pace and it can be hard to keep up. I’m going to tackle topics that I hope will make you think and reflect on the underlying challenges we face in our role. All the while pointing out many of the great resources available to admins and users alike.
More than Tech
As a final twist, it won’t always be focussed on administration or even technology. Sometimes I’ll dive into other topics such as mindfulness, strategic thinking, trend and data analysis, or even quick tips on random business applications I’ve come to learn. These are personal interest items that I find tightly woven with the role of an admin.
What is my goal? I can’t possible put into words what I’ve gained from the generosity of others within the community. May it be their blogs, hearing people present, following their social posts or having conversations with them directly about specific issues or problems I’ve faced, this community is chock full of intelligent, generous folks who share their knowledge at every turn. It’s time I try to give something back!
— Disclaimer —
There is one thing I need to be very clear about right out of the gate and you’re going to hear me reference often in my writings…
I am not here claiming to be the expert. I am sharing my thoughts and opinions on these topics. Even when I provide tutorials, I encourage you to chime in with your insights in the comments, especially if that’s to show a more efficient way of doing something. I am here to learn along with you, so please never hesitate to share your thoughts publicly, or privately to me directly.
I’m excited about this venture, and hope that it will be of value to those who choose to follow along!
In our last post, we set up a Model Driven App. CDS provides a fabulous foundational set of entities to work with, but sometimes we need to add our own flare to the system to ensure it meets organizational requirements. To this end, we’re at the stage where we want to create some custom entities to go with the out of the box entities.
We will work through the creation of a custom Registration entity to track each new application. We also create a Season entity and build a few relationships. Plus field creation, form editing, and adding these entities to the Model Driven App.
Join us as we walk through these steps.
We hope you are enjoying our unscripted walk through of these concepts. In this video we made a few missteps as we are still learning too! But we also shared several great tidbits (or timbits for our Canadian friends!) around planning best practices, relationships and currency fields.
What entities are we missing? What would your next step be?
Last time on the Power Baseball League Kylie got the environment all set-up. I’ve jumped in now and will build out the basic structure of the app with Contacts (people), Accounts (organizations), and Activities (interaction tracking).
I opted to keep this video short and only include the basics. We’ll build out custom entities and fields in future videos, but we need to start with the foundation first.
Follow along this video and see how you can have the basics set-up and ready to roll in less than 10 minutes!
To date we’ve spent a great deal of time planning aspects of this project out. We’ve discussed our goals, laid out some requirements and mapped out some elements of the data structure.
ENOUGH TALK – it’s time to start digging into the application!
Following our conversation with Nick Doelman, we finalized our plan; build out a Power App that leverages the Common Data Service (CDS). This will give us the functionality of a relational database while at the same time providing the flexibility to build it out as we need. It also means we’ll be able to leverage the Power Platform and Common Data Model to use hundreds if not thousands of other tools if we need them and still be able to pull that information back into the fold of our solution.
In this video, Kylie sets up the initial environment to get things rolling!
Special Guest Nick Doelman joins us as we start to design our app. We want to determine if we need traditional CRM (aka Microsoft Dynamics 365 Customer Engagement) or just a Power App based in the Common Data Service (CDS).
As two people who have been managing traditional CRM systems for quite some time, Kylie and I found our heads automatically go to “of course we need CRM”. But “CRM” as we’ve known it in the past has been changed. Now, we find purpose-built “apps” for things like Sales, Customer Service and Field Service. These are great tools and carry with them the best in breed features of the Microsoft CRM toolset. But what if we don’t need all those bells and whistles? What if all we need are the core entities involved, and then we can add and built out based on our requirements after that?
Nick’s blog post on the subject sheds light on this very topic, and we thought it’d be great to have him on with us to discuss the topic. We are grateful that he accepted! Have a watch as Nick outlines his thoughts on the subject during the recording here. A huge thank you to Nick for joining us for this discussion!
The Power Baseball League management system is starting to take shape! We have already discussed the data we want to capture so now we want to figure out how it all links together and talk through any additional data requirements. This is an important time to talk about relationships and how these relationships will influence the behavior of the system.
This is an interesting time in the project for this discussion. It’s an important aspect of planning our implementation as we need to think as thoroughly as we possibly can about the data structure we’ll need. At the same time we’ve yet to determine which system will serve as the foundation for this initiative, so we don’t have a system construct in mind.
As you’ll see, the discussion covers the core aspects of the project which bring us to a place where we can now begin to look at which system would be the right platform for this project.
We’re well on our way to building out a solution for our Power Baseball League management system, but we wanted to bring the project through the full process of the planning journey.
In our introductory session, we talked about the concept behind what we wanted to do. This was a much longer session that we’d envisioned as every time we turned a corner in the discussion we found more rocks to turn over and explore. It generated a ton of ideas and avenues we could pursue.
In this (much shorter!) video we review those ideas to determine what should be focused on first and how to make a manageable “Phase 1” release. You’ll hear us narrow down the scope and hone in on the basic requirements for that phase 1 release.
The Power Baseball League project was an idea I had a while back to build out a full youth baseball league solution using Microsoft Business Applications. I am excited to be working with Kylie Kiser, Microsoft Business Applications MVP, to work together to learn these technologies, share best practices and have fun!
The main driver behind this idea was a desire I’ve had for a long time to use a personal interest to build out a project that could leverage the different tools within the business applications suite. I’ve been involved in this space since 2010 – before the Power Platform was even known as such, and before many of the tools we have at our disposal hit general availability. It’s astounding to step back and look at what Microsoft has created over the years. It’s also overwhelming. There are so many tools available that it’s hard to keep up. Using a personal interest project like this helps one explore the various applications in a fun and unique way!
Join us as we talk about what this Power Baseball League is and the goals for our project. We will also start diving in to requirements to figure out how this project will play out. Listen closely for some best practices around requirements gathering that you can implement in your own projects.
Add your tips, tricks, questions and more in the comments!
People have thoughts and opinions, and your users are no exception. A user base that is engaged in the system and interested in sharing their insights and system desires with you at every opportunity is something system admins should aspire to. Even users that seem to complain about everything they come across in the system are, in their own way, sharing feedback with you.
The Many Faces of Feedback
Feedback can come in a variety of ways – a discussion at the water cooler, thoughts shared in a meeting, an email directly requesting a feature or system enhancement, an IM discussion, a support case, a note under the door, a sticky note left on your chair at the office…plenty of options exist.
Capture It All…And Be Consistent
Your role is to capture those suggestions and organize them in a way that you can action them in the future. There is no shortage of systems out there to help you do this. If you do a quick search for backlog and system enhancement software you’ll get list after list of the “top 10” or “top 15” lists according to various companies. Jira, Wrike, Asana, Teamwork…the list goes on and on.
Have a Plan!
No matter how the feedback comes in and what you do with it when it arrives, if you have a set process in place for this it will eventually become an action you don’t even think about.
Example: you get an email where a user has suggested some tweaks on a specific form in the system. Your process could be that you copy that text and paste it into a new System Suggestion file in your backlog/system enhancement management tool. You add who suggested it, the date, the context of their suggestion, and your anticipated next action item for the suggestion (i.e. call user to discuss further, send response with questions A,B,C for more information, review with system advisory committee, etc.).
Have Another Plan!
So you’ve got a process by which you capture those feedback items – GREAT! But what do you do with that list?
First – do you have everything you need on those suggestions? As noted above, sometimes the next action item might be to gather additional information from the user that suggested it. What I’ve found really helpful is to think about what I need to have enough information to explain the request to someone else. To do this, think about the W’s…
What change/addition is the user describing?
What is the business problem this is solving?
Where in the system is the user seeking this change/feature?
Who would be impacted by this change?
Why does the user feel this would be a positive change?
When does it makes sense to roll this feature into the system?
These are just samples. I’d encourage you to outline the questions that are important to you and your system/process/structure.
Additionally, have a schedule for this. Monthly? Quarterly? Twice a year? Point is, have some kind of systematic schedule that allows the steering committee to come together and review the suggestions.
Once you know what you need form the user, why not explore equipping them with a form that they can fill in when they have such a suggestion? Microsoft Forms Pro (err, Customer Voice…) makes creating a web-form as simple as it can be, and comes with some great features like question branching and notifications/alerts so you know when someone has updated a form.
If you know what information you need, why not ask it up front? This makes the process more efficient for you and the users, and gets you input you know you are going to ask for anyhow. It also encourages users to think about their suggestion. It’s a lot easier to rifle off an email with one line saying “I wish the system did a better job of X”. Having them fill in the form with specific questions pushes them to really think about what they are asking for and potential solutions to the business problem.
This can be tough. Remember that people are suggesting something from their perspective based on their experience. It comes with natural biases and is rooted in their understanding of and ability within the system. Those aren’t bad things, they are just things you need to be mindful of.
Not every suggestion is going to be a good one, but providing an avenue for your users to make suggestions is important to fostering their enthusiasm and buy in to that system – it helps provide them a sense of ownership.
But because of this, it’s important to have a ranking system in place. Often times organizations will have steering or system enhancement review committee. This is the group you will need to be able to explain the ideas to, however as there are often many suggestions to review, it’s beneficial to have a ranking system in place ahead of time.
I’ve seen different ways of doing this, but the most recent method I implemented really resonated well. It was a loose composite index model for system requests. Users were asked to rate their request on key business impact metrics. In this case:
Customer Growth Potential
The idea was simple. The user would fill in a form that collected key information about their request as noted above.
On the form the user would also be asked to rate the impact of this change on the metrics noted above – the scale we used was 1-5 with 1 being low impact and 5 being high impact.
I then weighted these. Revenue is pretty important, so it was worth 0.4, the other two items were 0.3. The user rating is then multiplied by this value to generate an overall “Business Impact” rating.
A user that provides ratings of Revenue: 2, Customer Experience: 4, Customer Growth Potential 3 would result in a business impact composite score of 2.9
This was part one, but Business Impact is only part of the equation. Upon receiving the submission the admin team would then add information into the index to make up the “Implementation Reality” index score. Also rated on a 1 to 5 scale, this would have the admin team rate the suggestion on the following metrics:
Time to Develop
Dependency on Others (as in, do I need to lean on other teams or vendors to get this done)
Time Waiting (how long the request has been waiting at time of review)
Same logic – a weighting was attached to each of these; 0.4, 0.3, 0.2, 0.1 respectively.
I managed these in Excel, so formulas drove the calculations and I had a separate tab that provided an graph to rate the priority. (yes, there are likely other systems to do this, but we needed something up quickly so started with Excel).
Items in the upper left box were the highest impact and easiest to implement, whereas items on the right side were more complex to implement.
This method provided me with a baseline ranking to help drive the discussion with the steering committee. I was able to articulate the weighting of each item, which helped the team understand the impact of the proposed item both on the organization AND my team, which was helpful.
That’s just one example, and I can see why some might look at this and think it’s a bit much. I’ve been in the scenario where I am trying to weight and measure the reality of implementation of a suggestion in real time during a ranking discussion. It’s not easy, so anything I can do help provide data to drive the discussion is pretty valuable.
The Overall Point
Perhaps this isn’t necessary, but a quick summary given the length of this post felt like a good idea.
Give your users a consistent and predictable method for sharing feedback
Capture EVERYTHING they toss your way so you have a lot to work with
(also, if you only keep track of the things you like or want to do, it’s kind of a form of favoritism and the reality is that this system belongs to the org, not you personally – perhaps this is a debate inducing comment…)
Ask questions so you understand the information from the initial idea submission
Have a ranking system on metrics that matter to your business and your team’s ability to implement
Have a schedule for the review feedback
I feel as though this topic could have been split up into a few parts. Perhaps I’ll circle back to this at some point in the future. In the meantime, what are your tips for collecting and managing feedback from your users? How to keep track of it? How do you prioritize it?
Drop a comment on the article or join the discussion on the social post that promoted it!
On the heels of the last post, I’d argue that seeing support cases is a sign of effective adoption (well, that’s probably a bit of stretch, but, it *could* be accurate in *some* cases!).
Supporting your users through their system journey is key. If you’ve been following along, you may recall the tidbit from the Training Framework post about ‘teach a person to fish, you feed them for a lifetime’. Well, sometimes the fisher-person needs some help getting the line untangled. We want our users to feel motivated and confident, even when they have questions.
What is the Point of Support?
First off, let’s ask ourselves what the point of supporting the user is. In my opinion, there are two key types of support:
Functionality issues (product – as in, the system isn’t doing what it’s supposed to)
Knowledge gap issues (user – as in, the user isn’t doing what they’re supposed to)
In both cases, it’s important that the user feels heard and you acknowledge you are aware of the issue. To this end one could gather that the point of user support is to ensure your users know you are there for them.
If it’s functionality related, you are going to need time to triage. Users want to do their work, so this requires a bit of a balance. In my experience the simply acknowledgement that you see their note about the problem and are aware provides assurances that you/the team are “on it”. I find these don’t need to be lengthy or complex – a simple “OH! Thank you. I’m digging into it now to get a sense of what’s going on!” can suffice.
If the issue is a knowledge gap, we’re in a slightly different ballgame, though there are some consistencies. First off, you may not realize it’s a knowledge gap item just yet, and triage it the same way you would a functional issue. Upon your own test you confirm it’s working as intended, and as such we now enter a period where we need to support the user through that knowledge gap.
This can be done with a quick explanation, or screensharing call to walk them through the process, pointing them to support resources that exist for the area of the system they are struggling with, or a combination of these things. Sometimes how we respond depends on how they approached us.
Oh The Ways To Reach You…
There are various ways incoming support requests arrive from your users….
They could ping you in Teams or another form of IM.
They could email you.
They could open an internal case.
They could call you.
They could yell over the office divider to you.
They could send you a carrier pigeon with a note.
They could swing by your office with candy or donuts or coffee and dangle it just out of my grasp until I answer their question (may or may not have happened before…to a friend. Ya, an admin friend. That.)
I think the manner in which you handle incoming support calls from your users depends heavily on the volume of those users. Not solely because there are some important data aspects you should consider which we’ll talk about, but generally speaking if you have two users and they are in close proximity the framework for user support is going to look very different than a user base that is geographically spread out.
But the underlining theme to whichever method you choose is that you need to demonstrate patience and a genuine desire to help. Predictability is key so users know what to expect when they put forth a request. This helps disarm users. I don’t mean users are angry or hostile, but let’s not forget that until they ran into this problem they were on their way to do a task to accomplish a goal and the fact they ran into a hurdle means they cannot complete that task therefore not reach that goal. They could be stalled until you get to them.
It’s More Than Troubleshooting
One of the considerations you may want to make about how you accept support requests is around how the data of those requests can help you. The most obvious scenario is that by collecting insights about the request, you can review those to understand trends in user behaviour or challenges with the system design.
Example: If users are constantly getting stuck on how to input information into a specific part of the form, perhaps the form design needs a review.
But like all analytics, depth of data is important. Just because one person had trouble finding that section on the form does not necessarily mean a revamp is needed. Read the example again – constantly. That’s an important word as it signifies that we have a recurring issue, and when we have a recurring issue we should seek to prevent that issue from arising all together.
I talked about user adoption and engagement in the previous post. If you’ve successfully engaged your users to the system in a way that fosters their desire to drive it’s efficiency and effectiveness, they are going to be vocal when issues arise, which is important to ensuring that the admin team can become aware of the issues so they can start to triage and diagnose the issues quickly.
Collecting data on the support requests also provides a window into the effectiveness of your training resources. If you have documents and videos created to help users through common issues, but you keep getting questions about those things because people aren’t using the resources, it begs the question if the users understand how to access those materials. Are they in a central or, better yet, logical location? Do users know they exist? (Remember: folks are busy – just because you told them a resource exists when you created it a year ago doesn’t mean they remember it’s there). If they ARE all those things, then it might be time to review/re-watch yourself and see where the disconnect is.
A Word on Support Speed
While it’s important to acknowledge the request in a timely fashion, this also comes with a dangerous caveat – if you respond and solve every situation immediately, your users are going to grow accustom to this and, in my experience, it breeds a sense of “don’t look for the answer, just ask and we’ll get the answer back right away”. This actually does everyone involved a disservice because there are going to be times when you/the team can’t respond right away. Particularly as systems grow and there are chunks of planning and new development needing attention.
How do we combat this? Set the expectations accordingly. Be open with your users – you can’t fix every issue that comes up in record time. You have other tasks and are juggling. Their requests are extremely important to you, but you need to balance your time.
Perhaps you set specific days or times that you spend on issue resolution. Or you set an auto-response on your case form that tells people you will read the item within the next X hours/business days/etc.
The point here is to be open and honest with your users about resolution times, as sometimes being the person who responds immediately to everything at all hours can be a curse on many levels. I speak from experience.
What are some of your staples when it comes to supporting users? Do you agree with what I’ve laid out here? Disagree? I am really interested in hearing what YOU do! Drop a line in the comments or join the discussion on social related to this post!
User adoption is one of those discussion points that never goes away. You can build the greatest system in the world but if people don’t use it, what good is it?
User adoption has to be top of mind for system owners. Any system needs to strike a balance of working both with and for your company. Put another way, it’s finding the sweet spot between the system having value to the users in terms of efficiency of their work while also ensuring the outputs of the system (data, reports, insights) are driving the business forward.
“If it’s not in [system x], it doesn’t exist”. Sounds easy, but it’s not. I’ve heard on several occasions “CRM is great and all but I hate that it’s so redundant – I already track all of that information in [spreadsheets/own files/other system/notebook/etc.]”. Ever seen those cartoons where someone says something and the response is a series of blinks back at the person? That’s generally how I respond, because my brain doesn’t compute the fact that the user doesn’t think to stop the ‘out of CRM’ version of the work.
It begs the question why the data management system isn’t the first choice? This is an important question. If users aren’t adopting the system that is put in place, something has gone awry.
So how do we find that sweet spot of user and business value?
The Basics of User Adoption
I think this boils down to engagement of the users themselves. Let’s be honest – near everyone has an opinion on how the system should be built. Providing the forum for users to fuel the discussion around system evolution is important. Asking users how they are feeling about the system – what works, what doesn’t work, what do they find “too clicky” an experience, and what parts of the system do they really like and draw value from, and so on. Asking your users for their thoughts and input is a great way to help them feel a sense of ownership over the system.
Like anything else, this can be a bit of a tightrope walk. On one hand, we want, no, need, input from the users on these things, but we also can’t accommodate every request that comes our way. I find transparency is best in this regard. Tell them outright – look, we want ALL the ideas, but we can’t necessarily incorporate every wish and request that is out there. The request needs to be rooted in some form of value proposition or prioritization measurement. I get into this more in my piece on user feedback management.
With respect to this post, the point is to engage the users in the discussion.
Keep Users Informed
Keeping users informed is an important aspect of managing their experience and ultimately helping them adopt the system. During my time with Big Brothers Big Sisters of Canada when managing their Dynamics CRM environment, I started “Dynamics CRM Town Halls”. This monthly gathering of users from across the entire country of Canada was an opportunity to share information. It’s entire purpose revolved around keeping users informed and providing a forum for their interaction.
They were structured in three parts initially – and it related closely to the Inform, Instruct and Engage methodology I wrote about in the Training article.
Each 90 minute session was broken into three parts…
The first 30 minutes was to inform the users of anything they might need to know about the system. Topics ranged from discussing up-coming updates, advising on what the steering committee was reviewing, pointing out strange behaviours users had been reporting (and where I as at diagnosing/triaging those things), updates from what Microsoft was doing with the product, etc.
The next 30 minutes was to instruct – I would look back at the trends of user support and drill into areas where I’d been seeing a lot of help desk requests coming in. I’d structure a short training on that topic and do a screenshare and walk through the system with attendees. These helped spread the news about how to deal with the issues so they could share with other users in their office (we had upward of 800 users spread out over about 100 offices from coast to coast).
The final 30 minutes was to engage – it was an open forum where folks could ask questions. Not necessarily questions of me, but of one another. Things like “how are other offices managing their activities lists?” or “what do you do if a match needs to change their schedule?”. The intent behind this was to develop a community of practice among users. I was a lone admin supporting a large user base spread out across the entire country of Canada (it’s big). I couldn’t be in every office monthly – in fact, I couldn’t have visited every office over the course of the entire year even if I wanted to! It was critical that we had a userbase that could engage with one another to work through issues.
These proved wildly beneficial. I ran them for many years, though eventually did tailor them back to every other month and even quarterly for a period of time, but I heard time and time again how much people valued these sessions because it helped them feel a part of a larger team of system-minded team members within our large network of offices.
Don’t Forget the Customer
We must also consider the impact on the customer. When the system is designed properly and provides the information users need to serve the customer, the ultimately beneficiary becomes the business by virtue of satisfied, returning customers. Of course the product must also be solid, but let’s assume that to be the case for the sake of this article.
Discussions about the value of the system to the user base inevitably get into what they want in the system. I’ve learned over the years to reframe it back to what do they need to be able to serve the customer. Perhaps that’s a subtle shift, but it can change the discussion in significant ways.
I first heard about this concept several years ago while moderating a panel discussion on system design. The popular and insightful Gus Gonzales shared that he has long used a methodology of system design around what the customer’s customer needs. I still remember hearing it and repeating it in my head several times – the customers customer…what!? As he framed his point, I was an instant believer.
I’m paraphrasing here, but the gist was to not build the system based solely on what the users say they need, dig deeper to understand what the customer they are supporting needs. If a customer calls in and is talking to a sales person, what information are they going to want the sales person to have on hand – THAT is the information the record should be showing the users, because it ultimately helps them make the sale or support the customer. It’s a really insightful tidbit that has stuck with me for years.
System Champions Foster Interest
The final point I want to make is a short one – find your user champions and use them to help spread the system joy. You likely know who they are already, but if not, they’re the ones that want to learn more about the system. They often ask plenty of questions of how to maximize the system. They are the ones that giggle when you present cool new features. They are the ones that put in system change requests with innovative, bleeding edge ideas. They are the “what if we could push a button and the system could do XYZ” kind of people. Find them.
Befriend them. Ask them to help you motivate and engage the team around the system. I’m almost certain they’ll be proud to do so. If you can swing it, get system swag for company events – they’ll wear it…proudly.
There is method to my madness. People tend to want to follow the herd. Not always, of course, but often. If the heard has strong champions…shepherds, if you will…they will find followers and they will proudly march down the path of system adoption and engagement.
What do YOU do to get users to adopt your system? These are just my ramblings, but there are other great insights out there. Feel free to chime in below with comments or join the discussion on this social post associated with this article!