Opinion: keep help public or put behind customer logins?

[phriend_o_phlair]

Without going into a lot of detail, I am fairly certain that our management team will be moving to take our help private (put behind customer logins). I do not feel that this is a good idea, but I would like to hear your thoughts. The software that we create holds the majority market share in our industry. Nothing in there would be "proprietary," really. Lots of articles on how to complete particular tasks, how to set up processes, how various fields/drop-downs/check boxes work, et cetera.

Please share any thoughts OR resources that might give me better understanding on this. I would be extremely grateful.

[RamonS]

What is to be accomplished by hiding help behind a login? Retain market leadership? Prevent copycats? Secure corporate secrets? Whatever the reason is those who are thought about should not have access will get their paws on it eventually. There is always the one or two customers who are not happy or shop around for other reasons and might be inclined to have the sales rep of the competition take a peek...or even print out the whole help.

If help contains something that is not to be known by the public do not add it in the first place. With that out of the mix there is no reason to prevent anyone from accessing the help. The only benefit I could see is that potential customers might want to have a look at the help first and having them register on a portal might make it easier to get their contact info. Although that would be different from a customer login.

Another aspect with a protected help is that it is then effectively off limits to any web indexing. The bots from Google, Yahoo, Bing, etc will not be able to index help and existing or potential customers will not have the opportunity to use any web search engine to look for items in the help.

I think hiding help is not a good idea, there are too many drawbacks for customers and little benefit for the company. I can provide some better advice if there is some more context as in why exactly the help is to be protected. Context is everything.

[phriend_o_phlair]

RamonS - excellent thoughts, thank you. A few points that relate to your response:

Several departments seem to feel as though the webhelp I built and tied into the app(s) is actually too robust when compared to the older .chm. Too helpful! If I correctly read the subtext of the unexpected VP-level pow-wow I was called into this morning:

• there is concern regarding the competitor's sales folks using our material to build a case that we are inferior on this or that feature
• copycat development
• sales of "support extras" might take a hit

Copyright/proprietary concerns could not possibly be a concern here. Funny thing... I have all our competitor's help.

I am amazed, actually, at how well things have gone since launching webhelp (we have help analytics for the first time in 30 years, rave reviews from customers/internal folks, responsive real time help deployments...); couldn't be happier myself.

I'm a big "information wants to be free" kind of person and I feel like locking the help down now that the customers are using it en masse would be a real "bummer," which is putting it nicely. I mean, we have a great product, so my stance is proceed confidently in a quality product and let that be our commitment.

[RamonS]

If there are weaknesses in regards to competition it is better to eliminate those rather than to hide their existence...at least my QA biased POV.
Copycat development isn't preventable and if it gets detected it is a matter for lawyers to deal with copyright/patent infringement. There might be other means of dealing with that, unfortunately only after it happened. My advice here is to not rest on laurels and stay innovative, that way there will always be more that other did not copy yet.
Support extras....so there is a concern that the help actually helps customers who otherwise would buy consulting or extra support services? While a valid concern, support should be all inclusive in regards to helping customers out and be based on a subscription model (like MadCap does it with the maintenance plans). The annuities work very well for many software companies and often they include an evergreen / free next version deal (like MadCap). MadCap has a tiered model that as far as I recall differs mainly in response time (phone vs email) but not quality.

Neither of these points really are a end user documentation issues but one of setting business priorities. My suggestion is to focus on what serves the customers best and hiding the help from them so that they are bullied into buying more support services doesn't strike me as an approach that is successful long term. In the end it all comes down to the numbers and I think it is fair to ask what the financial impact is compared to freely available and heavily restricted access to help.

You might want to take a look at the help content. Are there any portions that could be spun off into "Technical Bulletins"? I write quite a few of those and they cover interesting tidbits and things that look odd but are correct for our application. It is mainly intended for helping support, but unless labeled as confidential free to be passed on to customers. The help could still include a list of such bulletins, but they are only accessible through a customer portal and not available to the entire universe. That might strike a balance between providing information to customers and not revealing everything. Prime target might be those items that were identified as weaknesses, such as a data maintenance process that takes 12 steps where the competition might only use 4.
That might be a compromise without putting (potential) customers too much at a disadvantage.

[NorthEast]

Couple of thoughts:
- If your product is the sort that really needs help, and your help is really good, then your help is also a selling point and shouldn't be hidden from potential customers.
- If your help is already out there, unprotected, then isn't it a bit too late to start hiding it?

there is concern regarding the competitor's sales folks using our material to build a case that we are inferior on this or that feature
copycat development
sales of "support extras" might take a hit

Both points seem to rely on your competitors not knowing what your product does; but then isn't/shouldn't that be easy to find out?
After all, how do your customers find out what your product does?

What's stopping a competitor getting a copy of your product, speaking to someone who uses your product, or ringing your sales team to ask about features?

sales of "support extras" might take a hit

This point seems quite valid.
If part of your business model is to offer services/extras, then you probably don't want to provide the customer with full documentation on how to do this themselves; or if you do, perhaps supply it as a paid option.
Of course, if it's already out there, then it's probably too late.

[kkelleher]

(we have help analytics for the first time in 30 years, rave reviews from customers/internal folks, responsive real time help deployments...); couldn't be happier myself.

That analytics information could be a goldmine for your Marketing department. The promise of all that data is what led Marketing to fund our move to Flare in the first place. In addition to usage information (which can help direct both development priorities and tech pubs priorities), you can encourage your users to register, and then use their email address to feed your lead generation/Marketing funnel. We learn a lot about our customers this way, and we rank those people higher in terms of likeliness to spend money with us or renew their subscription. A person who registers and then looks at advanced topics in the system is more likely to actually buy our products, and we know something general about their use cases, too.

It's somewhat dependent on your go-to-market/sales model, but you might find an ally in your Marketing people.

Thanks,

Kristen

[phriend_o_phlair]

Thanks for your feedback. Awesome.

If there are weaknesses in regards to competition it is better to eliminate those rather than to hide their existence...at least my QA biased POV.

Agreed.

Copycat development isn't preventable and if it gets detected it is a matter for lawyers to deal with copyright/patent infringement. There might be other means of dealing with that, unfortunately only after it happened. My advice here is to not rest on laurels and stay innovative, that way there will always be more that other did not copy yet.

Agreed.

Support extras....so there is a concern that the help actually helps customers who otherwise would buy consulting or extra support services?

Yes. But I am not entirely sure if this is a warranted concern. I do not know if there has been any determination that this is the case, or just a bogeyman. One of the questions I asked when I first interviewed was "Is lowering support expenses an ongoing concern?" to which I got a resounding "Yes." But apparently it's a particular extended support package that they are concerned will take a hit. The impression I get is that we are heavily inundated with support/development projects. I will have to dig a bit to see if this is actually a desired state of affairs--or not! I have communicated that a big benefit of this online help is that it can help mitigate the easy issues so that support can focus on the trickier tickets.

While a valid concern, support should be all inclusive in regards to helping customers out and be based on a subscription model (like MadCap does it with the maintenance plans). The annuities work very well for many software companies and often they include an evergreen / free next version deal (like MadCap). MadCap has a tiered model that as far as I recall differs mainly in response time (phone vs email) but not quality.

Agreed. I will consider this.

Neither of these points really are a end user documentation issues but one of setting business priorities. My suggestion is to focus on what serves the customers best and hiding the help from them so that they are bullied into buying more support services doesn't strike me as an approach that is successful long term.

Agreed. All I know is that the majority of applications that I use (Both "major" and "minor") have freely-accessible help. Actually, scratch that. All of them have free help.

In the end it all comes down to the numbers and I think it is fair to ask what the financial impact is compared to freely available and heavily restricted access to help.

Agreed. That's the sticky wicket, really

You might want to take a look at the help content. Are there any portions that could be spun off into "Technical Bulletins"?

Hmm... maybe. What I think needs to happen is the growing of my team of one to be a more substantive hub of information.

I write quite a few of those and they cover interesting tidbits and things that look odd but are correct for our application. It is mainly intended for helping support, but unless labeled as confidential free to be passed on to customers. The help could still include a list of such bulletins, but they are only accessible through a customer portal and not available to the entire universe. That might strike a balance between providing information to customers and not revealing everything. Prime target might be those items that were identified as weaknesses, such as a data maintenance process that takes 12 steps where the competition might only use 4.

Extremely interesting point. We're now in "uncharted" but appealing waters, so I hope that we can carefully examine all the opportunities here. Last night I spoke to a buddy at another software company who says that some of their material is behind a log in for a similar reason. So I'm shifting to a less of a dogmatic stance... a little bit.

That might be a compromise without putting (potential) customers too much at a disadvantage.

Yeah, I don't want actual or potential customers at any disadvantage!

[phriend_o_phlair]

Really appreciate your reply, Dave.

Couple of thoughts:
- If your product is the sort that really needs help, and your help is really good, then your help is also a selling point and shouldn't be hidden from potential customers.

Wholeheartedly agree. The product really needs help. I'd say that the help is a notch below "really good," but it would definitely be an inconvenience to lock it away. Like... having the local gov't install 5 speedbumps in your driveway.

- If your help is already out there, unprotected, then isn't it a bit too late to start hiding it?

Hehe. I feel that way. I think doing so would have a deleterious impact and be an annoyance.

there is concern regarding the competitor's sales folks using our material to build a case that we are inferior on this or that feature
copycat development
sales of "support extras" might take a hit

Both points seem to rely on your competitors not knowing what your product does; but then isn't/shouldn't that be easy to find out?

Yep. I'm sure they have access the app in some way or another.

After all, how do your customers find out what your product does?

Exactly.

What's stopping a competitor getting a copy of your product, speaking to someone who uses your product, or ringing your sales team to ask about features?

Nothin'.

sales of "support extras" might take a hit

This point seems quite valid.
If part of your business model is to offer services/extras, then you probably don't want to provide the customer with full documentation on how to do this themselves; or if you do, perhaps supply it as a paid option.

Food for thought.

Of course, if it's already out there, then it's probably too late.

It's in a state of limbo in that it has not been indexed by any search engines, but is totally open and accessible. Hits are only coming from the app(s) themselves. The urls are being passed around and bookmarked by customers.

[phriend_o_phlair]

Hi Kristin! I wrote up a big reply and thought I had posted yesterday. I don't think I hit submit after all. Not gonna rewrite it, but I really appreciate your insights. The question for me is how to negotiate a lot of what is going on now that the help is moved out of a purely R&D paradigm an into a more... interactive corporate environment. Could be fun to figure all this out. I really want to figure out who the owner is for starters. As it stands, the only people who (get logins/are registered) are paying customers. Not sure on the sales process.

(we have help analytics for the first time in 30 years, rave reviews from customers/internal folks, responsive real time help deployments...); couldn't be happier myself.

That analytics information could be a goldmine for your Marketing department. The promise of all that data is what led Marketing to fund our move to Flare in the first place. In addition to usage information (which can help direct both development priorities and tech pubs priorities), you can encourage your users to register, and then use their email address to feed your lead generation/Marketing funnel. We learn a lot about our customers this way, and we rank those people higher in terms of likeliness to spend money with us or renew their subscription. A person who registers and then looks at advanced topics in the system is more likely to actually buy our products, and we know something general about their use cases, too.

It's somewhat dependent on your go-to-market/sales model, but you might find an ally in your Marketing people.

Thanks,

Kristen

[kkelleher]

As it stands, the only people who (get logins/are registered) are paying customers. Not sure on the sales process.

That's pretty similar to where we were a couple years ago. One of the biggest hurdles we faced was that we had been charging for our more 'advanced' content, and were praised internally for offsetting our own department's costs. And also, someone who is willing to pay for doc is an even more qualified lead than someone who just gives you an email address.

We had to convince the Powers That Be that 1) the increased volume of hits/leads and 2) the ease-of-use of our docs were more valuable than the doc sales income. Marketing was behind the idea, but the CEO took some convincing, especially since we didn't have any real-world data to back up our hunch. But it seems that we were right; having our docs freely available online has made a huge difference to our professional services, sales, support, and customers, and the docs are responsible for a good chunk of our leads. We never looked back.

Thanks,

Kristen

[RamonS]

Came across this article today:
http://www.teleread.com/chris-meadows/j ... -effective
It isn't exactly on topic because it isn't about hiding something behind a password, but the topic of restricting access to help comes up every other week in the forums here. The article not only shows that it is futile, it is also not liked by customers / users. So, don't alienate your customers and forget about having any good way to protect help content from "leaking out". If something is not intended for the general public do not put it into help files or any documents that are not and always were under strict access control.

[phriend_o_phlair]

kkelleher & RamonS - Excellent feedback, thanks a 10^6! This will go a long way to helping me sort though my thoughts. Great to have a forum like this to reach out to... you could charge for your expertise, ya know...