I think that could make sense down the road; maybe implementing an option for the DAO to signal that it doesn’t want the help button to be shown at all. We’d need to try this and see how it works, and if a lot of people want their DAOs to have their own knowledge base, we can find a way
I think this feature is a great idea and it is especially important for people who are new to crypto – for smoothing the on-boarding process with help docs and chat in more easily accessible locations.
Is there a reason that ZenDesk was omitted in the comparison/search? It seems their knowledge base theme can be customized and it’s the product that has the most adoption from what I have experienced.
As far as costs go, how many help seats are you imagining? I’m wondering if the shared inboxes will be limited toward the number of seats one is paying for.
I think the idea of it being configurable per DAO is interesting. But since all DAO transactions and UIs are already open by nature, it doesn’t necessarily have to be a DAO team that provides the support.
I would think that the primary use case of needing help would be something related to the UI or some failed transaction, as opposed to a very organization-specific query.
It is likely that DAOs will also have some chat rooms they manage, and organization-specific questions may more likely be directed in their chat channel vs. the Aragon help system.
Regarding the DAO-specific wiki this is something people will soon be able to build with pando.
I don’t wanna spoil too much and i’ll give more details on this very forum in a couple of days but pando will be on Rinkeby very soon for everyone to experiment with and the experimentation use case will be … an Aragon DAO on-boarding guide
I think this can be complementary to the Intercom like solution which I believe is a really good idea to help onBoard people.
I’d imagine around 5 seats or so, one for a UX person from each Aragon team, and then possibly a couple devs.
Also on Zendesk, AFAIK they are much more focused on corporate and their chat tools are inferior in terms of offering contextual knowledge base articles based on the message the user sends, which I think it’s a key feature of a system like this.
You are certainly right. But in my previous experiences integrating ERP systems (Odoo, etc) in companies, or also SCADA for industrial applications, a dual help system (one channel for the core components / basis UI, and another channel for specific use-case related help) always brought a lot of confusion to non-technical end-users.
That is great news! As we’re currently studying solutions for sharing and management of governance-related documents in a DAO, I’ll certainly take some time very soon to have a look at your work.
I have to admit that the main motivation for me to reply to this topic was because of the idea to see a centralized service natively integrated in the Aragon UI…
And so with my colleague we took some time to think about it.
So, what about something like this:
Help Center dapp
Help Centertab would open a screen with the following initial actions :
The Help Center would be an Aragon app featuring :
- Queue management system based on a smart contract.
- Integrated IM client based on some decentralized protocol, like Matrix (or Whisper 2.0?), that guarantees privacy and anonymity.
- Maybe also a ticketing system (also smart contract based) for issues needing more work or a more long term tracking.
On the helpers side
- Number of open helping seats at any given time would be automatically adjusted, based on a configurable SLA policy (average waiting time) by the DAO integrator.
- Helpers could/would have the following incentives :
- An minimum (timely based?) incentive for occupying a helping seat
- An incentive for every chat session started
- A bounty for every chat session that ended with the user signalling that his problem has been solved
On the help seeker side
- An on-boarding screen offering to search across existing knowledge base (maybe built on pando as @osarrouy suggested), or to initiate a support request (entering the queue with a SC transaction, thus protecting against spam).
- Eventual additional fee could be configurable.
- Ability to rate their experience (could have an influence on the amount of the bounty)
There certainly is still room for plenty of other design ideas.
And maybe the actions could also be accessible from the home menu :
What do you guys think ?
Would love to see that kind of help / support functions instead of a centralized commercial provider.
This is great, and I think that if there was a system like this in place, we wouldn’t need a centralized alternative. Unfortunately I’m sure a system like that would take many months to be built, but definitely should exist.
As Aragon grows, it won’t really be sustainable to have UX people or devs doing support – in traditional orgs there are always specialized support people and it’s a full-time job. How are you thinking that will be managed within this initiative?
I think it’s good to have the ownership outlined in these earlier stages – will it be something like the security partner where we eventually look for a proposal from a team solely focused on support and creating reports of common pitfalls (to help drive product)?
I think that there ultimately will need to be some type of supervisor once full-time support staff are needed, and the task being spread out across teams won’t necessarily scale.
As far as the product goes, I think the Help Scout option sounds good – I like that you can customize the branding. Also, I asked a friend whose friend does crypto support what they used, and they use Help Scout and like it a lot.
I think that could make sense down the road, having a team handling that.
Good to know, and also Help Scout is a public benefit corp, which makes me more at ease with using a centralized service. I think it’s the way to go.
Okay. We’ll try to gather resources and deliver at least a PoC before summer.
That kind of interaction is a needed feature for one of our key projects anyhow.
@everyone If someone is willing to help, feel free to DM me here or on Keybase.
I’ll hopefully come back to
this thread soon to show some progress.
Amazing!! Looking forward
Something to consider with the implementation of this is liability for the people responding to support inquiries. There should be an explicit release of liability for the support agent in case the user follows some directions and bricks their organization or something.
I am going to be working on copying / migrating some of our user guide documentation to Help Scout this week to prepare for the initial implementation. One topic I have been thinking about that has been in my mind since first beginning work on user documentation is how we want to organize the documentation for Aragon apps and who will be responsible for this documentation.
So far I have documented everything that is accessible from app.aragon.org right now (all developed and released primarily by Aragon One). But with new apps coming from other teams (e.g. TPS, Pando, Futarchy, Livepeer Delegator, etc), and potentially new related templates, there will soon be much more to document from an app and templates standpoint.
With this context, the question I have is: what exactly is the scope of documentation available in Help Scout?
Great idea! Probably would also make sense to have guidelines for the support person on which things s/he should handle and which ones should be left out for another instance (i.e. forum if opinionated or a professional if technical).
As I see, there are two interconnected but different problems to solve:
- How to inform and help users.
- How to learn from users.
For the first one, all the proposals seem great. There are some services that include a bot that works as a first filter to redirect people to the docs/wiki first. Even intercom has something like this. This would be great for scaling support.
On the second issue, I know this service called Canny, which helps to track user feedback.
I have a mixed feeling about it because it’s centralized and it also involves some discussion tools. It can add complexity to the whole communication system being yet another comm tool, but on the other hand, it’s specific and has a low barrier to interact with it.
I’m curious about docs too. I reached out to the hack.aragon team about TPS docs, but they said they we’re quite sure what to do. I was just going to start rolling them on my own in the context of a demo DAO that’s using them, but it would be great to have a more organized community led effort so that we don’t duplicate work.
I think that for now we should document the apps in
aragon-apps, and all the other officially supported apps. That’s a very open-ended term, and I think it makes sense that ANT holders or core developers decide on which ones are the critical apps that are important to audit, document, etc. Until then, we could just rely on our own judgment, and be open to feedback if anyone feels like an app needs to be documented.
TPS Documentation would be awesome!
I posted a status update and progression details about the decentralized help center idea here: