[bisq-network/growth] [CALL] Addressing the Bisq Support Workflow - Bisq BRIEF for November 21 (#164)

Thu Nov 21 08:17:06 UTC 2019

I guess from the thread here, maybe the way to go about it is to tackle it
in different fronts:

Knowledge Base
Email Support for high touch problems (i.e. the cases we had with the
corrupted wallets where arbitrators needed to manually sign multisigs)
social media low touch problems.

The KB functionality is currently done in github itself, but searching
there is pretty annoying. Example: I had Brazilians with a problem and they
found a solution, I couldn't find the tickets that described the initial
problem and there was no place to publish it to live on (it became part of
the workflow, then a bug fix and now will probably be fixed in the app) so
we can point at it when the same issue appears again.

KB usually converges into a wiki, which usually ends up being a ghost town.
How can we prevent that?

On Thu, 21 Nov 2019 at 08:27, Steve Jain <notifications at github.com> wrote:

> From my research, it looks like there is no magic bullet solution. I
> looked at a variety of privacy-focused services, and their support
> solutions seem to vary quite a bit.
>
>    - Some use email, plain and simple. Many times, emails forward to a
>    back-end ticket manager.
>    - AirVPN appears to use its own forum-like format for tickets, where
>    each ticket is opened with a web form. Tickets are only visible to users
>    who open them.
>    - ProtonMail uses ZenDesk, where tickets are opened by a web form.
>    ProtonMail is transparent about this and also gives users the option
>    to email them for support <https://protonmail.com/support-form>, which
>    is nifty since all data would then remain in their (presumably) secure
>    email environment.
>    - Njalla <https://njal.la/contact/> offers encrypted email and XMPP
>    along with a web form and some kind of "support system" that I cannot see
>    because I don't have an account.
>
> Special requirements for Bisq, as I see it:
>
>    -
>
>    Regardless of how support is "officially" handled, Bisq communication
>    platforms are destined to be disparate, especially as it grows around the
>    world, and people will inevitably reach out on all of them. Therefore any
>    solution will need to handle support requests coming in from a changing
>    array of channels. It seems to me that *a designated group of people
>    following a designated array of channels* (adjusted and adapted as the
>    user base changes) is the only way to conquer this. These people should
>    follow these channels, respond where possible, and redirect any unsolved
>    cases to the ticketing system.
>    -
>
>    Security and privacy requirements are high, so plain email won't work.
>    But not all users can be required to set up GPG keys to get support. Maybe
>    we offer Keybase as a more friendly fallback when secure communication is
>    required. Question is if/how Keybase can integrate with a ticketing
>    system...with email it's straightforward, but with Keybase it's not.
>
> Ultimately, I see the solution being a combination of tools:
>
>    1.
>
>    Informal replies/knowledge base. Designated group of 2-3 support
>    agents to watch Twitter, forum, Keybase, etc (exactly which ones need to be
>    discussed) and answer minor questions quickly and decisively. Refer users
>    to knowledge base where appropriate to avoid reinventing the wheel.
>    2.
>
>    If support agents cannot resolve the issue in the channel, they should
>    suggest opening a support ticket. Exact flow for this would be determined
>    by ticketing software, but would ideally be through a web form where user
>    can detail problem as well as Keybase identity or GPG key for secure
>    response.
>
> Support agents should correspond monthly to update the knowledge base so
> it remains current and useful.
>
> DAO elements of roles, bonds, etc would need to be determined too (as
> Fabio mentioned above) since it seems these support agents would have
> privileged access to the ticketing software.
>
> I'm not sure there's a way to avoid that, unless mediators and/or
> arbitrators were put in charge of handling tickets. Sounds far-fetched at
> first, but might be doable if we can get on-the-ground support and
> knowledge base really good...tickets should be relatively rare.
>
> —
> You are receiving this because you commented.
> Reply to this email directly, view it on GitHub
> <https://github.com/bisq-network/growth/issues/164?email_source=notifications&email_token=ABEY5S4WV6RGRV4VPR6L3L3QUYZ65A5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZHWWI#issuecomment-556956505>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/ABEY5S5RZ4RIC3636JRIRBDQUYZ65ANCNFSM4JI45OZQ>
> .
>

-- 
*Fábio Krauss Stabel*

+45 93 93 21 31

PGP keys
<https://keys.mailvelope.com/pks/lookup?op=get&search=0xE5058064B3E7342F>

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/bisq-network/growth/issues/164#issuecomment-556971272
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.bisq.network/pipermail/bisq-github/attachments/20191121/cad52895/attachment-0001.html>