Comments on How can we integrate a lightweight public ticketing system into our documentation feedback form?
Parent
How can we integrate a lightweight public ticketing system into our documentation feedback form?
We publish a substantial documentation set online. Each page has a place at the bottom that asks "was this helpful? (Y/N)", and if the person chooses "no" we offer a textbox. We collect all this feedback internally (it feeds into our internal ticketing system, except for the spam), but to the user, it feels like typing feedback into the void -- you never know when there'll be followup. Further, because the communication is one-way, we can't ask people to clarify comments when needed.
We would much rather have a public tracking system for these issues, where the response to the form submission would include a link with an invitation to track this issue. (We'd rather not ask for email addresses; this should feel completely opt-in and safe to the person offering us the feedback.) We want to find a place to host tickets that the public can follow and that we can update (either to say we've fixed it or to ask for more information). I'm imagining that all of these tickets would be created by us (well, by our feedback system) in response to the in-doc feedback, at least initially.
What tools should we consider? Opening our internal ticketing system to the public is not an option.
If we were managing our code (or documentation) on GitHub then using GH issues for this would seem obvious, but we're not, so it feels strange to create a project just to "host" issues for some other system. We're a for-profit corporation, not a non-profit or open-source project, and we don't want to step on toes or give a bad look by misusing tools meant for a different context. We also don't have a lot of money to spend on this and need to keep administration simple.
Post
Why not email?
We'd rather not ask for email addresses; this should feel completely opt-in and safe to the person offering us the feedback.
I assume this is a totally open system - no "login" needed. Because if a login was needed then you already have email and/or other information needed to connect an issue with a user.
In a totally open system, requesting an email address is about as simple as you can get while still being functional. It is a lot less than "create an account". If people are uncomfortable with this they can either use a throwaway email address (which may be a one-time use and they check it if they feel like it (which you won't know), may be a bitbucket (and you won't know), or may actually bounce).
Use this address to:
- Send an initial confirmation.
Just "Thanks for submitting" followed by the text of their submission, followed by "We will notify you if we make any changes or have questions blah blah blah" and "Reply to this email if you have additional information" (the Reply address should be oursystem-12345@example.com, where 12345 is the issue #, which with a little programming can be used to automatically add the replies into your ticketing system).
This message and any future messages should include:
An Unsubscribe link so that if either the submitter doesn't want any more messages or the address was fake (effectively spamming someone else) that it can be removed from your active list.
and
A "view online" link. Since this is open stuff and not confidential, this can simply be a link with the issue ID # plus some sort of hash to prevent casual unwanted random access (12345 was my issue, I wonder what 12346 is...). Not a true "login" - that is more complicated than necessary here.
- Send followups if appropriate.
The message was an actual honest-to-goodness useful suggestion and you implemented the suggestion. Or it was a complaint about inappropriate text on the page and you removed the text. Or whatever. You might never send a followup - e.g., if the original user message was spam or "thanks" or "your system sucks" or simply an issue you don't want to deal with.
- Never, EVER send actual marketing emails.
Your messages (initial and followup) can, and should, include your company information, but since this list is not positioned as a marketing list, do not use it as a marketing list. It should never leave the appropriate support department except individual items to appropriate people as needed.
2 comment threads
0 comment threads