CIDM

March 2022

Not THAT Self-Service

Headshot of a smiling man with short hair in a plaid button down shirt Lawrence Orin, Bringg

I recently started working at a company to create their content vision and build out their documentation and training. It’s part of a company-wide initiative to promote customer self-service, by offering self-help documentation and self-configuration, where users can access the settings they need to make their own changes.

Self-service as a business strategy is a win-win for customers and the vendor. When customers can configure the product independently, without requiring them to contact customer support to ask for customizations, they can use the product to its full potential, and the company saves costs on support and implementation.

It’s what we’ve come to call the enablement equation: Enablement = My Configuration and Content or E=mc2

While it’s obvious that self-service empowers our customers, it’s also worth remembering that content creators are also customers for authoring tools, content management systems (CMS), editing solutions and publishing solutions.

When we sketched out the user experience we wanted for our audience, we drilled down from the broad vision into the details, and eventually arrived at our list of requirements for each tool we intended to buy.

Then, armed with our list of requirements, we went shopping. We joined dozens of sales calls from a bewildering array of vendors, all trying to convince us that their product was the perfect match for our requirements.

All the while, we quietly held on to our belief that a tool should respect the enablement equation, E=mc2, to allow us to self-configure, to empower us to achieve our own goals whenever we wanted.

Fast-forward through all the sales calls, we compared each requirement to the features of the product, and concluded:
boxed text "Every tool should empower customers with self-service"

  • “No” if they missed any core requirements, or
  • “Yes” if they met all our requirements, or
  • An uneasy “hmmm” if they could potentially meet some requirements because it’s “in our roadmap” or they just need “a short customization”.

Whenever we heard “it’s in our roadmap” or “sure, you just open a ticket and we’ll customize it for you”, it made us feel uneasy.

“It’s out of the box!”

All tools allow their users to customize to aa certain extent. You can customize a word processor’s display of Heading 1 to be in Arial 18pt bold. Smartphone users can change the display to show a custom background image.

That’s an out of the box configuration, but that’s very different from asking for a customization.

Configurations are available for customers to independently change the behavior of a feature. When it’s a fully supported setting, users can feel safe knowing that as the tool grows and evolves over time with new releases, the setting will continue to be supported in future versions.

Some more advanced settings may be slightly less pretty, perhaps configured in a plain text file, but those files are still available for advanced customers to edit.

Customizations, however, are very different, because they are locked, not available to customers, because they require deeper changes to the underlying code to achieve the functionality required.

If a vendor says, “Sure we support that feature, it just needs to be customized”, try reacting in the same way any good writer would react: turn that passive sentence (‘needs to be customized’) into an active one. Ask the key question, “Who makes the customization? Can I do it myself? Or am I dependent on you?”

Cartoon of a huge man with the word vendor on the back and a small man next to him asking "when will I see the functionality?"

The Balance of Power

When a vendor customizes on your behalf, it’s both easier and harder. It’s easier because you just sit back and let someone else do it for you. But it’s harder because you are at the mercy of someone else’s priority list, their available resources, their sense of urgency, and their timetable.

You may find that you open a ticket, you wait, you follow up in your weekly meetings with them, they promise to get back to you, you follow up again, eventually it gets scheduled, you follow up again, perhaps it gets delayed, they finally deliver the functionality, you check it works, you uncover problems, you open more tickets, and so the joyous customization wheel keeps turning.

If you’re not sure who does the customization while you’re shopping, ask (even demand) to see the configuration page. Take the time to explore the settings yourself, to discover what you can control versus what’s under the vendor’s control.

This determines whether it’s a simple setting (configuration), or if the vendor must customize it for you.

Customizations have another danger, especially with SaaS systems. As the core platform evolves, there is a chance that your custom changes might stop working with the new version.

Once again, you are at the mercy of the vendor’s priorities. You must either delay your upgrade, or you fasten your seat belt and embark on another ride of the customization wheel of joy, with a new set of tickets, a new round of waiting, scheduling, confirming, discovering bugs, more tickets, and generally more joyous joy.

In contrast, a properly supported customer-facing setting would be tested as part of any new update. So when you shop for a tool, check that the settings pages you need give you the behavior you require.

Before the advent of SaaS, most enterprise platforms required an integration phase, to connect with existing systems and configure the behavior you need. This led to the popular adage that “All enterprise platforms need to be customized.” There’s that pesky passive sentence again. Who does the customization?

That may have been the paradigm 20 years ago. But today, modern SaaS enterprise systems like Google Suite, Chrome, Paligo, JIRA, Monday.com and dozens more, all work with large companies and all respect the enablement equation: they offer self-service to empower their customers.

It’s worth noting that consultants **do** respect the enablement equation. When you employ consultants, you remain in control. You pay experts for their knowledge and experience to do the work for you, but they work to your timetable and according to your priorities. They use their know-how to configure customer-facing self-service settings. Consultants serve you, not the other way round

Customize with Templates

boxed text "Ask not what your vendor can do for you. Ask what you can do for yourself!"Some vendors try a different approach to customizations; they create groups of predefined settings. Each profile or template can hide large numbers of complicated fields under a single umbrella.

You can see this approach in applications that offer preconfigured permissions for standard user profiles like an admin and a viewer.

You may have seen umbrellas like this when you set up a new email on a phone. Instead of wading through settings for mail synchronization, port numbers, and server addresses, most people choose the mail settings by picking from a shortlist of popular providers, which pre-configure those settings behind the scenes. A user only needs to enter an email address and password, and they’re good to go!

You may have seen umbrellas like this when you set up a new email on a phone. Instead of wading through settings for mail synchronization, port numbers, and server addresses, most people choose the mail settings by picking from a shortlist of popular providers, which preconfigure those settings behind the scenes. A user only needs to enter an email address and password, and they’re good to go!

However, these profile examples can be tricky, because if you find yourself outside all the preconfigured mail settings, you can still self-serve by configuring your own email provider, by filling in some user-facing settings.

It brings us back to the same question which still needs asking: “If I don’t fit one of your templates, can I self-serve, or must I depend on you?”

For example, when you switch on low power mode on your phone, it masks hundreds of small optimizations to use less power. If you’re lucky, you might catch 10% of them in the UI, but most are simply unavailable to customers.

In the product content world, you can see this in some documentation portals which offer customers a set of templated website layouts for a quick setup. They have a fixed look with only very narrow variations, because they hide often thousands of internal-only settings. If your vision doesn’t fit a template, you’re either left on the sidelines, or you’re invited to join the customization merry-go-round.

A fair solution that empowers content creators would offer a tool where you can design your docs portal independently, like Wix or similar web design tools.

Customize with Apps

Another way for vendors to allow their customers to self-serve might be to turn their products into platforms and let customers develop the code for their own functionality in the form of plugins, extensions, or apps. DITA, the open standard for technical documentation, is an old example of an architecture which uses the plugin philosophy extensively.

If you have coding skills, plugins can be a neat way to independently add your own functionality to fit your requirements, and of course the vendor wins by offering a safe and scalable way to extend the features and value of their platform.

As the world moved online to SaaS products, plugins morphed into extensions and apps. It became possible to add an open online marketplace for developers to upload their plugins and offer it to others. Pioneers in this space were web platforms like WordPress.

Letting customers self-serve was a massive boost to popularity. For example, WordPress became an overnight sensation, as customers could add any third-party plugin they wanted, or create their own. The platform could suddenly do so much more.

But in those early days, people quickly found that as the underlying platform was upgraded, the plugins also needed to upgrade with it, which became a problem when some developers didn’t upgrade quickly. Anyone using someone else’s plugin became dependent on them for added functionality, and suddenly found themselves back in a position of powerlessness, waiting for someone else’s priorities to upgrade their plugin. Another common complaint was that many plugins were incompatible with one another, as they clashed over the same resources and features.

This led to the invention of the curated App Store, popularized by companies like Apple and later Google, Microsoft, Salesforce and many others. In a curated store, developers must submit their apps through a strict approval process, to ensure their code obeys the platform’s technical rules, like remaining within their allotted memory space to avoid compatibility issues, or that they only use the platform’s official APIs, so they remain robust over time as the underlying platform evolves.

The plugin/app paradigm demonstrates how self-service can be wildly popular, and offers the classic win-win for vendors and customers. The only downside is that if you want to create your own app or extension, you must know how to code, and often it’s a proprietary language. For users of third-party plugins, you are back in a position of relative powerlessness, as you wait for someone else to address your needs.

Self-service: the sweet spot

Technical communicators create content for self-service, but in this article we discussed our own requirements for self-service. We are users of an entire ecosystem of tools, from authoring platforms to content management systems, right through to editing and publishing solutions.

If you are shopping for tools which need customization, carefully check the balance of power:

  • Ask **who** performs the customizations?
  • Do you have the freedom to customize whenever you need?

When a tool respects the enablement equation, it offers self-service for customization, which usually translates into a huge win for the vendor and a huge win for you, the customer.

Self-service can be:

  • Settings UI screens, where you can change the tool’s behavior according to your requirements, any time.
  • Plugins or apps with a marketplace can offer customization, but you need in-house coding expertise to create your own extensions.
  • Settings files should be in an established format (like CSS).

If some settings are locked, so that only the vendor has control, you are forced into a position of relative weakness, where your requests join a long queue of customer requests, all clamoring for the vendor’s limited resources. This often leads to delays, buggy implementations, and sometimes endless testing and following up on your part.

Instead, make self-service the cornerstone of any tool you purchase. During the proof-of-concept phase, ask to play with the tool’s settings independently, and be certain you have the freedom to make all the changes you need.

Some pointers for your next shopping trip:

  • If they say, “It’s out of the box”, check you have the control to customize if needed.
  • If they say, “Open a ticket, we’ll do it for you”, BEWARE! This puts you at a severe disadvantage and requires you to follow up to ensure your features are implemented.
  • If they say, “You can customize”, check and double-check that you can independently access **all** the settings you need to meet your requirements.
  • If they say “We have templates”, make sure a template fits **all** your requirements, without the need for further customization.
  • If they say “There is no customization”, only some simple user configuration settings, say “Yes!”

About the author: Lawrence Orin is a thought leader in technical product content, and has led documentation teams for much of the past 20 years. He has advised numerous companies on their content strategy, and currently leads the Product Enablement team at Bringg. Beforehand he was offering content solutions at Zoomin, and led doc teams at Radvision/Avaya and Aternity/Riverbed. He has also led teams in customer service and tech support. He has a background in programming, graphic design and content creation, and holds a B.Sc. in Computer Science with Cognitive Science from University College London.