I had no idea how much work was involved with selling items to students at an elementary school.

Which is a good thing. Because if I did, I probably wouldn't have volunteered to help out : )

But I was glad to have experienced it because the work involved reminded me of how it feels to be given a task without any procedures.

I felt stressed. I felt frustrated. I felt like quitting. And I felt exhausted. Which is exactly how your employees are feeling when they have a lot of work to do without any clear directions on how to do it.

Here's a typical explanation about what Salesforce is...

"Salesforce.com is a cloud computing and social enterprise software-as-a-service (SaaS) provider based in San Francisco." (TechTarget's definition)

You might also hear something like this...

"It’s an extremely flexible and scalable CRM system that is delivered via the cloud." (Tidewater's definition)

Nothing is wrong with those descriptions if you are talking to somebody who understands the lingo and the context.

But if that's how you explain it to your coworkers, don't expect any light bulbs to turn on.

The problem with those explanations is that they are meant to make you, the person explaining Salesforce, look smart. But explanations should focus on helping them, your coworkers who are learning about Salesforce, feel smart.

When you first train employees on Salesforce and explain what it is, skip the jargon. Forget all of the "interesting" details. And leave out the TLAs (three-letter acronyms).

Instead, package your explanation using guidance from Lee Lefever's book, The Art of Explanation:

"So... the Salesforce training documentation isn't interactive?"

Nope.

"Then what's the point?"

That's a good question. Although the question above is from a Salesforce Admin, I admit that I've asked myself that question after seeing fancy training tools like Captivate, Articulate's Storyline, and WalkMe.

What is the best way to take users from the "Land of Training" to the "Land of Doing"? And if interactive courses and guided tours are possible, then what's the purpose of a simple training aid?

After talking with dozens of Training Managers about this, here are the 3 main reasons static training guides are still in style (and why they're a great way to bridge the gap between training and doing).

Documentation goes by many names:

• Training materials
• Job aids
• User guides
• How-to manuals
• Checklists
• Standard operating procedures (SOPs)

And a few more. But to make things easier for me, I just call it documentation.

And it's clear to me that organizations and teams no longer need to be convinced that having better documentation is important - that debate (if it ever existed) is over.

Right now, the problem many organizations and teams face is creating documentation, and then maintaining it once it's written.

"What looks like a people problem, is often a situation problem. And no matter what your role is, you've got some control over the situation."

- Chip Heath, Dan Heath (from the book Switch - How to Change Things When Change is Hard)

If your Salesforce users aren't doing what you want them to do, it may be because they are stubborn jerks who hate change and refuse to follow orders.

Or, it might be that their environment doesn't make using Salesforce very easy - so they follow the path of least resistance (which is often the incorrect path).

Here's a video that discusses a principle you can follow to change your Salesforce users' behavior, and an example of one application of the principle.

One of the problems with blog articles is that they are one-offs. Going back to find an article that you really like isn't too difficult, but finding and sharing three or four that build on each other and teach multiple concepts is not easy.

So I decided to take last week off from blogging and instead put together a course for creating internal Salesforce documentation.

Reflect on live training events you attended in the past. How did they go? If you're like most, what you got out of the training depended on how you went into it.

If you knew nothing about the subject being discussed, and the training covered intricate details, it was like sitting in front of a fire hydrant. 

If you weren't interested in the subject, it was a huge waste of time. All of the answers being provided may have been great answers, but they weren't important to you.

But if you went in with questions, and those questions were answered, it was a great experience. 

When you put on your own training sessions, are your users drinking from a firehose? Wasting their time? Or is it a great experience for you and for them?

As Will Ferrell's famous SNL character, Harry Caray, would say, "It's a simple question" - why are you writing Salesforce documentation?

Are you doing it because you heard somebody at Dreamforce tell you to "document, document, document"? Are you doing it because... well... that's just what you do - it's part of the job description?

If those are your reasons for writing documentation, then you will never realize all of the benefits documentation can provide. You'll continue to write, and your end users will continue to ignore.