During our discussions up to now we’ve talked about how many of our constituents will need to continue filling in paper application forms to register their children in the up-coming season. To that end, we wanted to make sure our solution had a tool that could automatically read data, even hand-written information, from a form. Enter Forms Processing.
Phil, Principal Program Manager at Microsoft (and near honourary Canadian, he just needs a shot of maple syrup!), joins us to talk about his irrationally excited take on the potential of forms processing to help us in our project. We not only talk through it, but we also dive into the tool using our hand-written application forms and see it unfold in real time during the call.
THIS WAS SO COOL!!! Seeing a form that was filled in by hand get submitted and read – with excellent accuracy to boot – was super cool. There is no question this will benefit applicants for the Power Baseball League registration – the time savings alone will equate to hours saved entering data. There is only one word: WIN!
It’s clear this functionality has the potential to find efficiencies for any organization that needs to read data (printed or hand-written) into a system, and Phil’s enthusiasm about the topic is infectious! Many thanks to Phil for joining us on this video!
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!