Would you consider your Salesforce organization "twisted up" sometimes when it comes to documentation and communication? If so, your organization is in a "pretzel" - no, not the delicious snack food, but just tied in knots. That's where this helpful webinar comes in. In the "Unpretzeling Your Org" webinar, Michelle Hansen of NISC leads attendees through effective strategies for documentation - providing your organization the guidance it needs to remain consistent and informed.
To begin, Michelle explores both the value of documentation and why it's essential, providing insight into why this element needs to be a part of any organization. After that, she takes a look at the types of documentation an organization needs to have to be effective, and the ways different audiences (especially different generations of workers) prefer to receive documentation. Michelle explores the ways to consume documentation, addresses release notes for users, and then goes into a few different types of visual documentation options - specifically, the SIPOC diagram and the top-down process map. From there, Michelle looks at the importance of documenting automation and strategies for simplifying documentation. Finally, she addresses the mentality of "how can I get started?" along with various documentation tools and documentation for different audiences.
Michelle Hansen: (04:31)
Hello, everyone, I'm glad you're here. Just a little bit about me, first - I'm a Senior Salesforce Administrator at NISC. I've been working there for about 11 years and spent probably about eight of those working with Salesforce. I've focused on being an admin full-time for about the last four years now. In that time, I've managed to achieve Ranger status and nine certifications. I work with the Trailblazer community, both as a mentor and as a community group leader and Lightning champion. I absolutely love presenting, and I do it all the time. I'm thrilled to be here and thank you all for coming.
Michelle Hansen: (05:16)
We've got half an hour and a lot of ground to cover. Essentially we're going to start by talking about why documentation is important. Then we'll move into the types of documentation that you really should have for an org. We'll talk a little bit about how you can document processes because that's a little less intuitive for many people. Then I always like to wrap it up by giving you your "marching orders." That means, where do I start now that I've convinced you that this is something vital that you need to do. There's always help out there. I don't want to leave you stranded or feeling overwhelmed. So we'll finish up by giving you some more resources so you can continue your journey with documentation.
Michelle Hansen: (05:54)
Okay. So first up, why is documentation important? Usually, I would do this through audience participation, but since we're on a webinar today, we'll dispense with the audience participation. Some of the things that I hear most often is that I need to understand what the org look like looks like today. If I don't, then I'm pretty much stuck for two reasons: number one, if I don't know what it's supposed to do, I can't figure out if it's actually doing what it should or not when I'm troubleshooting. Number two: how do I know what to develop if I don't know what's already there? Documentation can also double as your training materials, so many people feel like it's just a waste of time, and it takes too long. However, being able to get kind of double duty out of it really makes it better for you to make that case to whomever else - be it your boss or your team - that this is important.
Michelle Hansen: (06:47)
Finally, it helps give you job insecurity. Most people ask, "What's job insecurity?" Don't I want job security? You know, "Don't fire me!" Yeah, that's true. We'll talk about that a little bit more in a minute. First, though - have you ever gotten passed over for a promotion or had your boss tell you that, "I just can't afford to lose you?" That's kind of the thing that we're going with here. Sometimes you can put yourself in a position to stymie your career or prevent your future growth because you've done such a great job of making yourself indispensable. So there's a kind of a fine line in there between being a secure, but not too secure. So, if it's so important and I've given you some pretty darn good reasons to document, why isn't everyone documenting their org?
Michelle Hansen: (07:34)
Many people will say, "I just don't have time," and "I've got other projects that I need to get to." So, they'll say that if they need to focus my time on creating documentation, it's just going to have to wait, or I'm not going to do it, or it's someone else's job - especially if you have a team you're working with. Maybe a business analyst or someone is developing those requirements and user stories, or a developer and admins. Some people are under the impression that, well, the developer wrote the code, they should be documenting it out. Their response? No, I just wrote this little bit of code, but the admin team is deploying it - so the admin team should be responsible for writing the documentation. Then everybody turns around and says, well, the analyst is the one who wrote all the user stories - so clearly if they're the ones who know what it's supposed to do, they should write the documentation.
Michelle Hansen: (08:20)
It's always a fun game of finger-pointing for some people, especially when they're new to Salesforce or walk into a very large organization that isn't well maintained. They're not really sure where to start. Sometimes it's that overwhelming feeling of, "I don't know where to start, so I'm just going to not look at it and pretend it doesn't exist - and maybe it'll go away." Many people also think it's too expensive - we need documentation software, and we need to get all of these fancy tools, and we just can't afford it; it's not in the budget, so "I'm not going to deal with it." Finally, as I mentioned, the opposite of that job insecurity is "job security." If I know how this works and nobody else does, they can't fire me. Therefore, it's in my best interest not to let anybody else know how this works, so they can't ever get rid of me - which works great until you're the one ready to leave or move on.
Michelle Hansen: (09:11)
If you're in a position where your supervisor or your team doesn't very well understand the value of documentation, it's good to be able to make that case. So there are three key aspects that we'll talk through that you can use to kind of convince them of the importance of doing this. First: accelerated development schedules. If you know the organization's current state, it's much easier for you to start designing towards that future state. If you have to actually go back and understand what that current state looks like, it's going to add up in terms of time. I've thrown just some examples of different things that you may need to do as an admin. For example, if you need to go look up a field and figure out what it does (this assumes it's maintained well and has documentation), there's a description that tells you what it does.
Michelle Hansen: (10:01)
That's probably going to take you about three minutes - the same thing for accessing a page layout or examining an email template sent out with some sort of an email alert. That alert gets based on activity that goes on in your org (depending on how complex it is) reviewing formulas, formula fields, or workflow rules and validations. Those could take you about five minutes to work through each. So, if you have to do more than one of these for the particular project, you have to start adding up processes or flows. That might take you 10 minutes or take you 30 minutes or may take you more depending on the complexity. This is just what I'm looking at from an admin perspective; we haven't even factored in looking at Apex code. So if we say on average, it's going to take you a day - eight hours of your time to go back and look through what is in your org - on an average salary of $75,000 a year, that adds $300 in costs to that project and a day of time to do it. That is in addition to what you're not working on for current projects, because you're going back and doing this rework.
Michelle Hansen: (11:07)
That doesn't seem like a whole lot, but it starts to add up when you add that to every project you're doing. There's also troubleshooting, since you need to understand what the expected behavior is. How is it designed to work? What should happen when the user does A, B, or C? Then, how can that compare to what the actual behavior that you're seeing? Also, because we want to know how it works in terms of design, is it good enough to compare that to what the user is actually doing? Often, you can find out that the error you're getting is because of your user, as opposed to a problem with your Salesforce architecture; maybe they are a very creative user. I've had a few of these that have co-opted a process for something you never designed it for.
Michelle Hansen: (11:58)
Clearly, the actual behavior is not what they expect - but that's because the expected behavior isn't what they were looking for. It is working as designed; it's just not doing what they thought it showed, or they're using it for a different case. Now where this really adds up is training time. As I mentioned, your documentation can double as your training material. Think about someone coming into your company - your company that uses Salesforce - and they've never even heard of it before. You've got to start from scratch - this is how you use an account, this is what an opportunity is. It's going to be a solid hour or two just to go through how you navigate Salesforce and use it with all your org's objects.
Michelle Hansen: (12:44)
Then you add in training on the processes that your company has built into Salesforce - your sales process or case processes for customer support, for example. We're going to say another four to eight hours of training on that, assume that you train them once and it sticks. Then every time you add new functionality, we need to teach them some more. So if you create new things, that's probably 30 to 60 minutes worth of training. If you update a process that they're used to and change it, that's probably another 30 minutes that you're going to spend teaching them how to redo the process this new way. Then, of course, everyone pays perfect attention in meetings, right? You've never had anyone answering emails, taking phone calls, stepping out, having dogs, cats barking in the background as we all work from home, right?
Michelle Hansen: (13:34)
More than ever now, refresher training is essential, because someone wasn't paying attention or doesn't remember, since it's been a while since they've had to do it. So they ask you to walk them through it again; depending on what the process is, that could be anywhere from 10 to 30 minutes. When you start to multiply that by how many users you have and how many topics you could be training on, that could be days, weeks, or even months of your time spent going back over things that you have already trained on. Again, we can certainly estimate that at two weeks a year. That's almost $3,000 in your admin time alone spent retraining users and not getting other work done because we're going over already covered territory. We're not even taking into account a sales manager salary or other employee salaries spent getting retrained and what work they're not doing.
Michelle Hansen: (14:32)
With that, let's keep that in mind why it's crucial. What sort of documentation should we have to be effective? First of all, there are three different types. I want to talk about customization of your org, then focus on documentation specifically for your users, as opposed to your admins or developers. Then I want to get into process diagrams. These are very useful for both because I want to talk about your business processes and any automations that you've built into your organization (often overlooked) and all of these things together. Along with that, there are some other choice morsels to become what I call an admin handbook. The admin handbook you can think of as if you were to go on vacation for a month and needed to leave your org in someone else's hands, what do they need to know to keep it running until you come back? More importantly, what do they need to know that they shouldn't touch until you are back? After all, there are some things that you should have the admin handle.
Michelle Hansen: (15:28)
As we're going through this, there are some considerations I want you to keep in mind while you're writing documentation. You need to keep in mind who your audiences are. There is not going to be just one person that you're writing this for. If you are, that means you're probably writing multiple versions of documentation - which you don't want to do. So think about the different people involved in your process. Think about your inputs and your main actors in your outputs. For example, if we're talking about expense reports, your inputs are the sales reps that need to put their expenses into the system. The main actor, then, is going to be that employee supervisor, who reviews the inputted expenses in the expense report and then creates the output, which is the approved expense report document that then goes to accounting. Accounting is also an output because they're the ones that are going to get that report and then have to do something with it.
Michelle Hansen: (16:21)
So are some of these are users? Are all of them? Or are some of them management that want to be a little bit less hands-on? Are some of them admins that will have a much more in-depth knowledge of the platform and can speak to the lingo or understand some of the acronyms that you may familiar with, whereas other users or management may not. What are their knowledge levels? Are you writing this for the new employee that comes off the street that's never even used Salesforce before? Or is this targeted towards someone who should understand some of the processes in your organization? If it's an admin, are they advanced? Are they a power user, so you can skip some of the more manageable steps and go right to the heart of the new process?
Michelle Hansen: (17:06)
How it's going to get consumed is important - more than ever, these days. A lot of us have started to move away from working every day at a desk or a laptop with a computer. So it's great if you're writing in Word doc and you put it in a PDF, and you throw it in Salesforce. Someone can access it from their PC; they can pull it up, and it's no problem - but what happens if they're on mobile and need it to be mobile friendly? If you've ever tried to read a PDF document on a screen, that's about four inches by five inches. It's challenging, and it's very small. Is there a way that you can put it together differently that makes it mobile friendly? You may have old-school people every time you send them documentation, the first thing they do is print it and put it in a binder on their desk.
Michelle Hansen: (17:51)
That's going to be a challenge you have to work with because they need to get an update every time you make changes. Again, this format doesn't just have to be paper or PDF. Again, if you're going mobile, can you do something different? Maybe it's a YouTube video, a Tech Talk video, or a walk-through or something that they can see and access easier from a mobile device. So documentation types that we're going to go through. First of all, we want to talk about your value, your customization in Salesforce. Validation rules and formulas, custom objects, custom fields - all of this information really should get documented in Salesforce. They have a description field there for a reason. They have expanded recently out to more fields about the level that this goes to - is it internal or external?
Michelle Hansen: (18:46)
Who's the owner of this data? So if we need to get it updated, we know which group to talk to, but it's more than just putting a description in the name field that says it is the name of the record. I can probably figure that out from the title, but why are we putting it in here? How is this getting populated? Is it part of integration to a third party system? Is it filled out through automation? Is a user responsible for doing this? Those kinds of things help you understand how this gets populated, where else in the system it may get used if it's in a report or something like that so that you understand the impact of other changes that you make in the org. You can also make sure that you don't delete a field that suddenly disappears from 50 or 70 reports comments.
Michelle Hansen: (19:29)
It's actually really cool. You can do this in code, and everybody's pretty familiar with that, but you can also put it in your validation, rules, and formulas. So what you can do is you can write out what you're trying to do in English. I won't want to see if the opportunity stage field is a closed one, and if it has, is this timeline field? If so, throw an error. Now that I've written that out in English, I can then translate it into a formula, which makes it easier for admins after me to come and understand what it's supposed to be doing. Plus, it's a great way to ensure that you have multiple criteria that you're using everything appropriately. You can do this in a spreadsheet - I'll show you a couple of versions, and you can do this by ops object or by release, which is how I tend to do it.
Michelle Hansen: (20:16)
By object - I'll have a link to this later in the presentation - you can pull in all of your different fields and all of the information about those fields as shown here. You can even display which record types they go to. So it gives you an excellent one-stop-shop to look at where this field is? What's it used for? What are the impacts of it by release? I use this as my checklist when I'm ready to move things between orgs. So when I'm working in a sandbox, everything that I built, if it's a custom field or a custom object, page layout, validation, rule flow, I write everything down here. Then, I use this as my checklist when I'm ready to move it, and I can go back and see when things got added because it's by release.
Michelle Hansen: (20:58)
The second type of documentation we need to have is for our users. Number one, release notes. Salesforce is a huge company. If release notes are good for them, they're good for us. It keeps your users up to date on the new things that are impacting their job. So you can be a little creative to make sure that they do get read. I can tell you from experience throwing in an email and letting my users know there's new stuff out there generally makes it to the bottom of the reading list, not the top. Here's an example of what I do for release notes. I make sure I put the date of the release and the platform version that it was on. Then I have a highlight section that gives us kind of a one-page overview of all of the things that I've released, then a footer at the bottom that makes sure everyone knows this is internal only - so my legal team doesn't get upset with me. Then in each expanded section, I put the icon that relates to the object in Salesforce that we're talking about to start solidifying some of those relationships. Finally, after I've explained it in detail if it's pretty complicated, I will put together how-to documentation and add a link to that right in my release notes.
Michelle Hansen: (22:07)
So speaking of how-to documentation, this is basically where I go for users that are new to the system or new to complicated processes - step-by-step instructions. If you remember the idiot's guides to everything from the 1990s and 2000s, you could learn how to do pretty much anything, and it would take you there from the beginning. This is my goal. If someone walked off the street and into my org, would they be able to take this document and complete this process without any assistance beyond the document I gave them? You can also do this within app guidance, which is new with summer 2019. So I would encourage you to use the option that works best for your users. Again, for some of the things that we do here, I use a lot of screenshots. I use a lot of numbers.
Michelle Hansen: (22:48)
If there are things that need to go in specific orders, I always put in a "What's in it for me" section - because again, if someone doesn't understand how this impacts them, they're not going to bother to read it. Then, I use formatting and where to hyperlink it so they can jump to appropriate sections. Process diagrams are supposed to be a visual representation of a process that is much easier to understand. They always say that a picture's worth a thousand words; that is definitely true for processes. I can write a 50-page document that explains every step, but if I can put together a one-page flow chart that you can follow, that's going to be a lot easier. Plus, it helps you document the current state of what's happening today. You can then add to it and say, okay, this is what we do today, but here's the future state I want to get to you.
Michelle Hansen: (23:39)
Also, what are the steps that it's going to take to help me move from where we are to where we want to go? You can add multiple layers and most of the tools out there to have different levels of complexity or information based on your audience. So what you're going to show to your managers is going to vary widely from what you show to your users who need to use the process every day, and then what your admins need to see, to build and support it. So how do we document processes? There are a few different ways. Business processes have a lot of different options. So this is the slip-up SIPOC diagram. It gets your suppliers, your inputs, your processes, your outputs, and your customers. This is identifying who is responsible for what. This is great if you're trying to ascribe responsibility, but what it doesn't do very well is show you kind of the steps. A top-down process map is a little bit better.
Michelle Hansen: (24:31)
A top-down process map is a little bit better because it shows you the start of a process, and it gives you the ability to have a couple of different layers so that you can drill down into it. So the top line boxes could be for your management, the detailed steps below for your users. It doesn't necessarily show who's responsible for what, but it gives a good progression of how you get from the start to the end of a process. Flow charts are always great if you have decisions and logic - if the answer is one thing, you go this route if it's another thing you go a different route. This is a kind of a step up from the other two, but we can improve on this a little more by adding swim lanes - which not only give the flowchart concept but also start to show you who's responsible for what. The one thing that always kind of throws me with these is that they have all these different shapes to represent different things.
Michelle Hansen: (25:22)
Quite honestly, I can't remember what they are. So something I found recently is "universal process notation," and it basically combines all of these. It just uses boxes and words, which everyone can understand and follow, to walk you through a process. So every box is what's happening and who's responsible for it. Then you have the lines that will show you what happens next. This is basically the why of where we're going for the next step, so you can still step through the process. It still gives you the ability to have branching logic, and depending on the tools you use, again, you can make attachments or drill down so that if some of these are processes of their own, with additional steps, you can link them all together.
Michelle Hansen: (26:06)
Automations also need to get documented. A big reason why I say this is because a lot of times in your Salesforce work, you're going to have automations that cross different objects or impact different things. If you don't keep all of that in mind, making changes to one object can definitely lead to problems elsewhere. I've run into this myself. This is going to help you understand different things about your org. What exactly got selected? What are the objects involved in this process? Is it running in user motor system mode? What kind of permissions do they have, and then what actually happened? When you're troubleshooting by documenting out all of these different things, when someone comes to you and says, "I don't know if this worked right," you can follow this diagram and figure out if it did or not, and if not, why? So we'll take a quick example - a closed opportunity. Everybody's excited when we win new business, right? So the sales manager goes in, they update the opportunity to a closed one, an email alert gets sent out that we won new business. Everyone's excited, pretty simple, right? Two steps.
Michelle Hansen: (27:15)
When I started to dig a little deeper, no, there's a lot more than that happens. So the opportunity gets updated not only by the user but also through automation, triggering a process. The process calls a flow, also called a second process, and does some updates. The opportunity products flow fires, and it updates the opportunity because it's looping over my opportunity products. Then, that invocable process gets used to send out an email alert based on a specific email template. Now all of a sudden, we've gotten a little more complicated. So to document this, I started by identifying everything. That's part of the process, whether it's a person and action or something that's acted upon or dependent on something that's acted upon. For example, I've got my salesperson, the process, the flow, my opportunity in my products, and my email alert and templates.
Michelle Hansen: (28:12)
So when we go through here, this is what's happening by or to each of these different items. The salesperson is updating a stage on the opportunity. The process gets called because that gets updated. It's accessing a flow; it's updating an opportunity field and calling it an invocable process. My flow is looping through my opportunity products and updating an opportunity field. My opportunity again is being acted on. So I need to keep it here. My opportunity products, the fields, and the records of those opportunity products are being looped on by the flow and opportunity products get created from actual products. So I need to keep that in scope because if I make changes to products, that may potentially impact something upstream. Then, of course, my email alert gets called by a process, and that email alert gets tied to an email template. So I need to make sure that that's top of mind if I'm trying to make changes to my email template.
Michelle Hansen: (29:09)
So here's what this ends up looking like when I dig into it. The customer signs a contract. The sales team updates the opportunity because of that. The process fires and updates, and the field calls a flow. I have a subprocess down here for what the flow does, but I've also itemized each of the pieces within here that get impacted by this step of the process. This is an easy way for me to have a one-page document that I can see and view every object that is getting acted upon.
Michelle Hansen: (29:44)
I know we're running short on time, so I want to make sure that I get through some of the rest of this - but where do you start? Start where you are. If you need some suggestions on where to get going, number one, what's business essential? If you won the lottery and quit your job tomorrow, what would they need to know to keep things going until they could hire another admin? Then also, start from now. The next thing that you do is to start documenting it. Use these things to ensure that you're not getting more technical debt or more pretzels in your org because you're not documenting. Then it's less for you to go back and have to fix. Finally, if you start from now, there are a lot of different tools that you can use. Some of these, I have used; many of these I have not.
Michelle Hansen: (30:29)
I can't speak to how well they are going to work for what you want, but for documentation, there are many things out there from elements that cloud down to field footprint or a field trip that are app exchange apps you can download. Some of them are free. Some of them do have a cost, or there are both paid and free versions of both for process mapping. Those are things like LucidChart or draw.io. I mean, even Vizio or PowerPoint can work for that. Wiki documents are not terrible. Sometimes it's good just to have things that you can go back in and document all the weird foibles in your org. So try a Google site or building it in Salesforce, even, as a way to make sure that your documentation is around then. I mean, you can start with something as easy as Excel. If all you have is the Excel Suite or even Google Sheets, you've got enough to start documentation - and there's no excuse for that. If you want to go with training videos or walkthrough snippets or anything like that Camtasia to Zoom, they all have great tools to grab screenshots, do walkthroughs, video editing, all of that great stuff.
Michelle Hansen: (31:38)
Dreamforce 19 had quite a few sessions on this, and you can access the recordings from the Dreamforce site. I like to include these in case you're looking for some more information, and these include how to document Salesforce within Salesforce, how to use Quip, and all sorts of great things to help you build your documentation. Then, of course, there are different styles out there. Everyone learns and does things a little bit differently. By no means, am I the only expert out there, or even an expert at all. I'm learning right along with the rest of you. So here are some more readings and videos. Here's one of those Wiki pages that you can go to, and you can look and see what some other people have done find the style that resonates best with you and start instituting that at your org.
Michelle Hansen: (32:24)
Several of the things that I showed here I have links to all of the templates. You are more than welcome to download these and start using these. Some of these are my own; some of these I found elsewhere on the website or the internet. So by no means do I take credit for the content that's here. With that, I want to wrap it up and leave a little bit of time for questions. Again, thank you for inviting me to present here, and I guess we'll see if we've got any questions.
Leonard Linde: (32:59)
Thanks, Michelle. Yeah, we do have a question. How do you ensure your documentation is simple enough for your team?
Michelle Hansen: (33:10)
Sure. That's something that has to get done more by feel. The biggest thing I've noticed is the more I get into Salesforce, the harder it is to look at it with fresh eyes. So, find somebody with fresh eyes and ask them to review the documentation and see if it makes sense. I know Salesforce in and out. I've built most of our work. It's my baby. So if I take my newest user and hand them a document, I'll go, okay, I'm working on documentation. I need you to see if this makes sense to you. If there's anything that you have questions about or that isn't clear, then come back, and let's talk about it, and I'll modify my documentation as I go. Later in the future, I can remember why that wasn't clear. So do I need to break it down into smaller steps? Did I use terms they're not familiar with? I try to make those adjustments as I go so I don't do the same thing in future documentation. So short answer? Ask them.
Leonard Linde: (34:03)
That's a great piece of advice. You know, I liked the slide on cost savings. Have you used that technique with your management to try to get it?
Michelle Hansen: (34:15)
I'm very fortunate to have a great team that backs me up, and we're expanding our use of Salesforce quite a bit. They've embraced the platform and the opportunities that it offers. So I'm very fortunate to be where I am and to be able to work with Salesforce the way I do.
Leonard Linde: (34:37)
Are there any of those documentation tools that you found more compelling that you use? I mean, it looks like - from your examples - you just use good old Excel. Your release note - which looked really nice by the way - it looked like a Word document.
Michelle Hansen: (34:57)
Release notes right now, we do in Word. How-to documents as well. I'd like to get some more of that. Then I post them into Salesforce as files, so they're accessible. I'd like to get more of that into Salesforce. Quip would be fantastic if we ever got that. When it comes to being able to do some cool stuff with documentation, I can't say enough good things about Elements.cloud and Spekit. Both of them have a cost. Elements does have a free version for process mapping. Between Elements and LucidChart, those are probably my top two favorites. There are going to be limitations with the free version, so just be aware of that. If you can use one of those, those are probably my favorites that I have used.
Michelle Hansen: (35:40)
There are many of them here that I have not gotten a chance to use. ScreenFlow video card - I know about them, but I've never had a chance to use them. Metazoa - I've seen some demos, and it looks pretty cool. A lot of these, especially when they are app exchange apps, actually get an insert digging into your metadata and can tell you a lot. Elements.cloud, for example, will tell you what your field usage is and what the impact is of changing that field based on how many other places you use in your org. Is it in your automations? Is it in your reports? If I delete this field, am I going to blow up the org?
Leonard Linde: (36:15)
Recently, we did interview both Ian Gotts and Melanie Fellay. Ian's from Elements.cloud. He talked about the process flow diagrams. Melanie also spoke about how Spekit works. The way I'd characterize those two as Elements is more of administrator, behind the scenes type documentation. I'm sure you could show this process diagram to users. Spekit is more right in the Salesforce document giving on-demand support at the user level.
Michelle Hansen: (36:57)
Absolutely. It's kind of like enough guidance on steroids with cherries on top.
Leonard Linde: (37:03)
User satisfaction, I think, is going to be higher in well-documented orgs. In fact, it will be a lot higher because when you just throw somebody at Salesforce, it's all ask the person next to you or in the next cube.
Michelle Hansen: (37:30)
Especially in these days, when we're working from home.
Leonard Linde: (37:33)
It seems to me that in a well-documented organization, I bet your users are happy. Even though nobody loves reading documentation, I bet it's happier than a place where there isn't any.
Michelle Hansen: (37:54)
We've gotten better adoption as our documentation game has gotten stronger. When I first got here, we didn't have a lot of documentation. Every time we got a new employee, we had to sit down and hold their hands through the process. Then, one of their coworkers had to teach them the system on ride-alongs or hand-holds. That's great. However, what if I'm off that day, and you have a question? If you've got documentation that you can refer to, you can at least try and help yourself. We live in a world where people are much more likely to use a kind of self-service, and they don't want to have to call someone for help. So, if they can do it on their timeframe with tools available to them, they will be happy. By helping them understand how to learn it, the adoption's going to be there. When they adopt the things that you use, they're definitely happier because, as an admin, your goal is to build something that makes your users' lives easier.
Leonard Linde: (38:49)
Got another question from the audience. Do you find that specific audiences, users, administrators, management consume documentation differently or better desktop versus mobile versus print?
Michelle Hansen: (39:01)
Oh boy. So, it's not always users versus admins versus management. The company I work for has a pretty big gap in tenure. We've got the people we've hired straight out of college, and we've got the guy who's been there for 45 years. Guess which one of those likes print better? Sometimes it's the older generation that prefers paper and having something that they can physically refer to you as opposed to the documentation. Before COVID, when people traveled, my sales team would be out with a phone and a tablet. Something that they can get to you on the phone or on a tablet is going to be much more critical for them than something where they have to be able to open an email and download an attachment.
Michelle Hansen: (39:52)
Honestly, I don't know if most of my management team reads my release notes. I can tell you that my manager does, at least, because I usually get, "Hey, good job - this is fun functionality." I get excited. It's released. However, out of my a hundred or so users, I get about two or three of those emails. So, I mean, what does that tell you about my readership levels? The good thing is, is at least when questions do come up, I have somewhere to refer them back to you and say, "Yep, we did document this." You know, "There is a change in Salesforce, you're right, you did catch that, let's review what it is." If you need some more help, we can schedule a meeting to walk through it.
Leonard Linde: (40:27)
I think at some point, people do learn when you redirect them like that. We have a couple of minutes left. Did you have anything more that you wanted to add about back orientation or famous last words that you want to give us? Like like your elevator pitch for doing this or something?
Michelle Hansen: (40:47)
Honestly, anything is better than nothing. It does not have to be perfect from the beginning. I'm presenting on this, and I am by no means perfect because truthfully, it's two-fold. Number one, to learn something, the best way is to teach it to someone else. Number two, if I'm going to start presenting on this, you better believe I'm not willing to be a hypocrite. So this forces me to do my documentation to a better degree than I might otherwise. Sometimes that's what it's about, but anything is better than nothing. So even if you start small, just, just make sure you start.
Leonard Linde: (41:18)
I think that's good. That's good to know because I think you definitely could feel overwhelmed if you just try to document your whole order at once. So thanks, Michelle, I really appreciate your time and your presentation.