By Beth
Chmielowski

Software as a Service, or SaaS applications, are different in the way they are purchased, consumed and supported, but at the end of the day, they are just tools people use to get things done. There is nothing fundamentally radical or even new about the purchase, consumption or support models, yet taken together, they offer a paradigm shift that is upending the traditional software marketplace. Similarly, training for SaaS is different in the way it is designed, delivered and sold, but at the end of the day, it is just a tool people use to learn. And here, too, each individual element has been in play for some time, but bringing them together offers a whole new take on enterprise learning that is upending old school practices. This article is the first in a series of three exploring these key elements, and how to structure each to maximizing the effectiveness of SaaS training:

  • Designing SaaS Training
  • Delivering SaaS Training
  • Monetizing SaaS Training

This first article focuses on how to approach training design to keep pace with the fast-changing world of SaaS applications.

Designing SaaS Training

The biggest challenge of designing training for SaaS applications is maintenance. SaaS apps can change so frequently, that traditional long-form training buckles under its own weight trying to stay relevant. No sooner do you finish a comprehensive course then it is obsolete. If ever there were a place and a need for agility, it is in the cloud. Here are some basic design tactics for developing compelling, effective, and nimble SaaS training:

  • Use a blended model: As with any training, identify your audiences and their needs and determine the best modality or blend of modalities for each.
    • Determine if there are any critical audiences that will need focused instruction, feedback and support. These often include operations teams, admin users or evangelists who will be the “go to” people for the rest of the organization. Focus time and resources on ensuring their acceptance, expertise, and advocacy. These are the prime audiences for instructor-led training, preferably in person, if possible.
    • For enterprise applications with a broad user base (such as 20,000+ users), minimize the amount of instructor-led training (ILT) for end users as much as possible. Even an hour-long course presents a scalability issue with that many users. Designed right, self-paced learning (whether online eLearning, or “off-line” self-study) can be just as effective, and tends to be both faster and lower-cost from a training deployment total cost of ownership perspective. If you introduce self-paced training from initial implementation, it is easier to maintain that approach with each new release.
    • Be sure that minimizing ILT does not equate to minimizing interactivity. Whatever the modality, including hands-on, discovery-based activities is critical to learning, acceptance and adoption.
    • Augment self-paced end-user training with regularly scheduled opt-in webinars, or online “office hours,” for those who have questions or would like additional hand holding.
  • Keep the documentation out of the training materials: Do not include screen shots or step/action/results tables in the training materials.
    • Push “how to” content to a set of short, discrete, self-paced demos at the task level such as, “How to add a user,” or “How to create an opportunity.” These should be short, 1-3 minute demos that people can consume in the moment of need.  Keeping these granular and task-focused is key to staying current with SaaS releases. With each release, there should be only a sub-set of demos that will need to change (unless the whole app is re-skinned).
    • Make these demos available online, and ensure there are no barriers to access. That is, don’t make users provide an additional login, force them to go to a training environment or make them complete anything as a pre-req for access. These should be available to all users regardless of whether they have gone through training. Ideally, host these demos and make them available from within the app itself, if possible.
    • Point to and leverage these materials during the live or self-paced training so users know they exist and are available for access and self-help when back on the job. Ideally, whenever a “how to” question comes up in class, point people to the library of demos first to see if they can find the answers themselves.
    • Note that the focus of these demos is different from online help. The latter is meant to focus on features and functions, or what a button or field should do. Instead, these demos should focus on tasks, or what the user should do, which can span multiple buttons, fields, features or screens.
  • Design discovery-based, scenario driven training: Keep the materials focused on the processes that the SaaS application supports.
    • People need to learn how their processes will be changing given the introduction of this new tool. The “as is” processes will vary from client to client, and the “to be” processes may also differ, given the flexibility and configurability of SaaS apps. However, the super-set set of processes that the application supports will be consistent across clients.
    • Design the training scenarios around those processes, creating discrete modules for each. You can then aggregate the appropriate sub-set of modules for each client, based on the functionality they have enabled for their configuration.
    • The scenarios themselves should be generic, yet prescriptive. For instance, if training on a CRM tool, you may have a scenario built around creating a new account. Provide generic instructions to “Create a new account” and supply parameters to use for the data entry: Account name, contact name, contact title, etc.
    • Build the scenarios around a fictitious company for continuity between modules, but make sure each module functions on its own. That is, do not introduce dependencies between modules, as not all customers will use all modules. For example, do not have a scenario of creating an account in one module and a scenario for adding a sales opportunity for that account in another module. The “create a sales opportunity” scenario needs to be based on a dataset that exists regardless of whether or not the “create an account” module has been completed earlier.
    • Tightly define the training dataset required to support each scenario. Having a training environment with a baseline dataset is critical to successful discovery-based learning.
    • Design training to move from basic to more complex tasks, building skills as participants’ progress through the materials. Ideas for doing this include:
      • Start with a UI “treasure hunt” to orient users to the interface
      • Introduce simpler scenarios with more prescribed data early and more complex scenarios (or less prescribed data) later.
      • Provide “challenge” exercises on advanced functionality for power users or for those moving more quickly through the materials.
      • For group training sessions, have people work in teams. “Jigsaw” the modules so each team works through different scenarios, and then have the teams present what they learned back to the larger group, highlighting important steps and calling out any “gotchas” they may have encountered, along with how to avoid them.

Note that keeping the documentation out of the training, and keeping the scenarios generic and process focused makes maintenance much simpler. With each new release, updates are focused on identifying any new or changed tasks, modifying a subset of the “how to” demos, and perhaps building a few more. The scenario-based training materials should have little to no changes release to release. Because the scenarios are generic to the point of simply telling users to do something, changes to how that thing is done will likely have little impact to the scenario. Updates to the training materials themselves will typically only consist of adding additional scenarios when a release introduces new processes that the SaaS application supports. And in those cases, this results in creating an additional module or modules that can be snapped in and delivered to those customers who end up implementing that new functionality.

The next article in this series will explore best practices for delivering SaaS training, with a particular focus on formal, agile and social learning, and a discussion of how learning portals can be used to harness and maximize all three.

Share