search

bisq-network / growth

Bisq exchange growth experiments
https://bisq.wiki/Growth_team
24 stars 11 forks source link

[Call] Addressing the Bisq Support Workflow - Bisq BRIEF for November 21 #164

Closed m52go closed 4 years ago

m52go commented 4 years ago

Call details

Everyone is welcome, and there's no need to RSVP or register, but if you do plan to attend, please add a 👍 below so we have an idea how many people will be there.

Topic / Agenda

Stepping Up Bisq Support

Lately support has been rather disorganized, in general...it's spread across too many channels, with no designated handlers, and has been compounded by an uptick in frustrated users caught in the update to v1.2.

The situation needs to be improved. On this call, we'll discuss current conventions, pain points, and paths forward. User feedback will be critical here to help us pinpoint gaps.

See this proposal for a starting point.

Call details

Zoom: https://zoom.us/j/322825254

Web (no Zoom software required): https://zoom.us/wc/join/322825254?pwd=

ripcurlx commented 4 years ago

Just a couple of free and open source tools I found with a quick web search:

Does anyone have experience with those tools?

ripcurlx commented 4 years ago

Best case feature set for me would be:

FKrauss commented 4 years ago

silly question, but I guess it's not only on my mind.

What are the unique properties of Bisq support that a regular ticketing system does not fill? i.e. Zendesk or any other similar service.

I see mainly the following, (please add more):

  1. Email support relies on having emails and identity, making support people a trusted role (as opposed to self service support or community provided support)
  2. Many of the concepts around these ticketing system imply a company that has targets for resolution time and whose staff has the power to actually do things (like modify data in the backend). although not entirely, as you can also have support for products that are not a sort of SAAS offering
  3. there is no incentive to close these support tickets (please note the distinction between a github issue/ticket vs a support ticket) -> if there is an incentive on a per ticket basis, there is also an incentive to cheat it.

Although maybe there is a setup that comprises what @ripcurlx mentioned above. i.e support agents pay per month for their seat on Zendesk (using it as a placeholder for the ticket system) and hold a BSQ bond, this way there is a mini barrier for scamming, it costs you the setup and there is somewhat of an individual reporting for the agent to request compensation... but I don't like it because it makes it even more of a trusted role where someone needs to be this Zendesk Admin

If we can mitigate these I believe we can shape a decent support structure. And I do think that nowadays we are just spread too far in too many places, which is a consequence of community provided support (I myself onboard users in Brazil via our Pt-br telegram group).

Right now I also see a few layers of support.

front-line: community second-line: documentation (as much as I'd want this to be the first, it is always easier to ask around than to read documentation) third-line: Slack / keybase / forum last-line: github(I'm sorry but as much as I would love to use github issues for support, only developers have github accounts, regular users do not)

Is this the structure we believe is the ideal?

Let me know what you think, and I'll join the call too, so we can chat about it!

Cheers

FKrauss commented 4 years ago

Looking around I found these:

Non Open Source:

  1. https://freshdesk.com/ - seems ok, supporting everything zendesk does too.. not sure if a good option.

Open source:

  1. https://osticket.com/features/ - seems more focused on a CRM like thing then in actually ticket system
  2. https://www.opensupports.com/features/ - this one looked the closest to what we need from what I could parse from the website and the presentations. It is self-hosted too
  3. https://zammad.org/screenshots - seems to be bare ones ticket system via Email
  4. https://www.uvdesk.com/en/opensource/ - didn't quite get the open source nature of it
  5. https://helpy.io/all-features - seems interesting, data control is one of the things they pitch, although no mention of encrypted messaging, nor social media support

What's a common theme:

Overall, from looking at the websites the one that looks simpler and closer to what we need (without really passing with flying colors due to no encryption) is the OpenSupports (number 2).

There's also the option of looking for a paid solution that offers NGO/non-profit packages.. maybe we can get something like that in the freshdesk or zendesk ones. But I would go that path only if the OS ones are really far from what we need.

has anyone had any experience with these? Am I hallucinating?

m52go commented 4 years ago

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.

Special requirements for Bisq, as I see it:

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 may not be very common.

FKrauss commented 4 years ago

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@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

ripcurlx commented 4 years ago
  • 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.

One way to solve this, suggested by @wiz, is to include support within the Bisq app and use the onion address as identity handler. Support requests are sent similar as we do it with the mobile notification service over a relay server to forward the requests to a support API. Encryption and decryption of the message when forwarded to the support system of our choice has to be discussed.

ripcurlx commented 4 years ago

Maybe similar to arbitrator/mediator selection a random support agent is selected and the message is encrypted with its public key. The support agent has to decrypt the message after in the support tool of choice.

FKrauss commented 4 years ago

the only issue is overwhelming the support agent with low touch requests, things that would be solved by checking slack or so.

maybe we make a mix of helpcenter/knowledge base articles and support chat? Similar to what most websites have where you first need to dig the KB a bit before you can talk to a human for support

On Thu, 21 Nov 2019 at 10:13, Christoph Atteneder notifications@github.com wrote:

Maybe similar to arbitrator/mediator selection a random support agent is selected and the message is encrypted with its public key. The support agent has to decrypt the message after in the support tool of choice.

— 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=ABEY5SY25YL37M4GASPUQJ3QUZGLNA5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZQCEI#issuecomment-556990737, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEY5SZTVGK634J7SZU3A73QUZGLNANCNFSM4JI45OZQ .

-- Fábio Krauss Stabel

+45 93 93 21 31

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

ripcurlx commented 4 years ago

the only issue is overwhelming the support agent with low touch requests, things that would be solved by checking slack or so. maybe we make a mix of helpcenter/knowledge base articles and support chat? Similar to what most websites have where you first need to dig the KB a bit before you can talk to a human for support … On Thu, 21 Nov 2019 at 10:13, Christoph Atteneder @.**> wrote: Maybe similar to arbitrator/mediator selection a random support agent is selected and the message is encrypted with its public key. The support agent has to decrypt the message after in the support tool of choice. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#164?email_source=notifications&email_token=ABEY5SY25YL37M4GASPUQJ3QUZGLNA5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZQCEI#issuecomment-556990737>, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEY5SZTVGK634J7SZU3A73QUZGLNANCNFSM4JI45OZQ . -- Fábio Krauss Stabel* +45 93 93 21 31 PGP keys https://keys.mailvelope.com/pks/lookup?op=get&search=0xE5058064B3E7342F

Unfortunately the regular common support SDK integrations with this KB article suggestions is no way for us. Implementing it ourselves might be quite a lot of work. Maybe it is enough to point the user to the knowledge base website first and if she opens a support ticket within the app it has a cost (BSQ?). But I probably would be pretty pissed if I have to pay for support if there is a bug in the app itself.

ripcurlx commented 4 years ago

Or we hide the opening of the support dialog with a keyboard shortcut that is revealed after you haven't found anything in the KB? Of course that will only be a one-time hurdle, but could prevent the initial flood of noob support requests.

FKrauss commented 4 years ago

Can we do deeplinking? you know, like slack has: you log in the browser and then redirects to the app (although they are an electrum app, i.e. a mini browser).

if yes we could simply prompt people to go to the help center and then deeplink them to a command to open support. As in a helpcenter it is trivial to add a search box and recommendations and all that fancy fru fru

Anyways, I guess we have plenty of material to munch through before the call. Let's just make sure we're effective in discussing it.

I would suggest we do the following agenda, assuming not everyone will have read this thread but just so we give enough context for those who didn't so they can still contribute to a valuable discussion:

that adds up to 55 min... I hope that is enough time to cover everything and I can keep us on track for the time too

Do you agree, or shall we take a different order/set of topics?

On Thu, 21 Nov 2019 at 10:45, Christoph Atteneder notifications@github.com wrote:

Or we hide to opening of the support dialog with a keyboard shortcut that is revealed after you haven't found anything in the KB? Of course that will only be a one-time hurdle, but could prevent the initial flood of noob support requests.

— 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=ABEY5S57FDXRJEJTWNRMSGLQUZKB7A5CNFSM4JI45OZ2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEEZTGMQ#issuecomment-557003570, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABEY5S4R2J7PM2DLTBIWP5TQUZKB7ANCNFSM4JI45OZQ .

-- Fábio Krauss Stabel

+45 93 93 21 31

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

ripcurlx commented 4 years ago

Can we do deeplinking? you know, like slack has: you log in the browser and then redirects to the app (although they are an electrum app, i.e. a mini browser).

Haven't looked into it how difficult it is to do it cross OS properly for Java apps.

  • What is the current state of support (to put everyone in the same page) @Steve, could you talk about this? - 10 min - What is the desired state of support (ignoring any constraints how would it work from the user and the DAO perspective, assuming problems exist and users don't have to become sys admins to get support) - I can moderate this one - 15 min - What are the tools / functionalities we need to have in place - 5 min - Outcome: a clear list of agreed functionality we need to do - What are the constraints we have in bisq specifically? - 5 min @chris, could you talk a bit about this? - Which tools exist that could fill these and which functionality would have to be built? @Steve and I can talk about these - 10 min - Assigning implementation goals - who owns what and who helps who? @Steve and I can also lead these, I can also take ownership of further research or writing docs/specs for whatever we uncover above - 10 min

Sounds good! For me the goal of this call is to have someone that leads this feature request, creates a proposal based on the decisions made in the call and after it finds consensus pushes it to get implemented and integrated into the client asap.

m52go commented 4 years ago

Sounds reasonable to me, thanks Fabio. I'll make a slide with this agenda so we can have a visual guide for the discussion.

clearwater-trust commented 4 years ago

Can we add a quick security assessment for the different systems that may be suggested? Maybe consider worse case scenario if the system was compromised. What data will reside server side to make it work for our setup... and other security things that I don't even know about.

ripcurlx commented 4 years ago

Can we add a quick security assessment for the different systems that may be suggested? Maybe consider worse case scenario if the system was compromised. What data will reside server side to make it work for our setup... and other security things that I don't even know about.

I think to make that as safe as possible we have to have encrypted messages on this systems only and the support staff has to decrypt them in command line or some other decryption tool locally. If we do that it doesn't matter so much if the system is compromised.

ripcurlx commented 4 years ago

We also must not pass the onion address as identity to this system, but rather some other handler and only the relay server knows the matching onion address to send the response to the right peer.

m52go commented 4 years ago

Screenshot from 2019-11-21 12-42-35

m52go commented 4 years ago

Recording uploaded here: https://youtu.be/Pyl_eK5NNig

Check out #ticketing-system on Keybase if you'd like to help!

Closing as complete.