Private Label or Co-Brand Your Help

Does everyone know what it means to private label a product? Or to co-brand one?

Let me explain it through an example, then I’ll move on to how to make your life easier when building a help system.

Private Label Scenario

Let’s say that I make a software product called:

Rob’s Antivirus Great Software Stuff

There’s a toll-free support number. There’s an email address. There are 63 features and 20 product screens, each with their own special name.

Great!

Now let’s say that a corporation (let’s call it, “Big Brother”) wants to give or sell my product to their customers. But they want to call the product:

“Big Brother Special Sauce”

They have a different company logo and colors, they want to support it themselves (using their own phone number and email address), and they want to disable certain features and screens. (Maybe they have other products that handle the features they’ll disable in this product.)

This kind of thing happens all the time.

So it all gets worked out. Every detail is organized through painstaking legal discussions and developer meetings. Months go by and finally the deal is done.

Then someone remembers the help.

The Big Brother tech writer gets a call. Can you please go through the 400 topics in the help and make some quick changes?

It’s easy:

1. Simply change the contact information.
2. Simply delete certain features.
3. Simply change the name of the product.
4. Simply change the colors and logo.

It’s all so simple!

Oh, and this happens even when it’s not private label

For example, you’ve written the help, but the feature (or product name) changes. Or the Support number.

In an earlier post on this site, Dinos Lambropoulos talked about dealing with those kinds of changes. (Link below)

I’ve gotten a few calls like this, and I can tell you that it’s not simple.

Why it isn’t simple

People expect me to do a “simple” Find and Replace for the name of the product. Just replace every instance of “Rob’s Antivirus Great Software Stuff” with “Big Brother Special Sauce.” How hard can it be?

But then we end up with sentences like this:

Big Brother Special Sauce will do all this for you in no time. That’s why we put “Great” right there in the name.

Or, we never find out that the original writer sometimes referred to “Rob’s Antivirus Great Software Stuff” as RAGSS:

“Remember RAGSS is there to help you.” And the reader says, “Whaaa? How does Big Brother become RAGSS?”

Finding and replacing alone just doesn’t work. You have to go through each instance to make sure it makes sense. This goes for anything beyond the most basic change.

What drives me crazy about all this is that, given a little foresight, it could be so simple.

Why it could be (more) simple

Let me start off by saying that I use Robohelp. I assume that any Help Authoring Tool (or HAT) worth its salt can do the same kind of thing, but I won’t swear to it. So the rest of this post is about Robohelp.

If there’s the slightest possibility of a private label deal in the future, here’s how you build your help (this post is too short to explain how to use these things, but it’s long enough to explain that they exist. Find out how to use them in your HAT, and then… use them).

In short, you control what appears in any given version (or output) of your help.

Variables

When creating your help system, you don’t type the name of the product as “Rob’s Antivirus Great Software Stuff.” Instead you type (or otherwise enter) a variable, like “[long_product_name]”. The short name isn’t “RAGSS,” it’s “[short_product_name]”.

Then you can control how those variables get filled in. You change a setting in your HAT to say, “hey, when I’m building help for Rob’s company, change “[long_product_name]” to “Rob’s Antivirus Great Software Stuff.”

When you want to build help for any other company, you tell the HAT how to handle each variable. You only have to do this one time and in one place.

Same goes for phone numbers, email addresses, or URLs. Use [support_phone_number] and [support_email_address], etc.

But you’re not finished.

Conditional build tags

Conditional build tags let you reserve a topic, sentence, or even a word for a given version of your help.

For example, remember that we want to write:

Rob’s Antivirus Great Software Stuff will do all this for you in no time. That’s why we put “Great” right there in the name.

Here’s what we’d put in the help:

[long_product_name] will do all this for you in no time. That’s why we put “Great” right there in the name.”

The red part is “tagged” to show up only when building the help for Rob’s company. If you choose a different output (that is, a different company to produce help for), then that sentence simply won’t appear in the final help.

You don’t have to think about it every time. You think about it only when first creating the help.

You can even add conditional tags to index items, if you don’t want those items to show up for certain outputs.

Mix it up

With a savvy use of variables and conditional tags, you can cut the work of private labeling by a huge amount. This bit of foresight (and extra work at the outset) makes life vastly easier down the road.

See:

Earlier post about variables from Dinos Lambropoulos