What do you think if we integrate Intercom into Anytype?

We have tested different ways of communication and feel that we can make a better online support inside the app. In terms of in-app chats, there is no proper open-source self-hosted alternative for Intercom. Chatwoot looks promising but doesn’t seem to be production-ready. Self-hosted proprietary services looks worse than open-source, have closed codebase and somehow cost thousands dollars. Could Intercom integration result in you not using Anytype? We guarantee to use it only for support and assistance.

1 Like

I don’t know: I don’t really like the idea of having a(n unnecessary) piece of (closed and external) software lying around as I type my notes.

If there would be a way to disable it, I would without thinking about it twice

9 Likes

For support, its okay for me. But I think, should not be integrated, more like a webview, so its encapsulated and only loaded when really using support.

4 Likes

I’d tend to agree with what has already been said.

I understand the need for something that does not take the next month of Dev time to be integrated, but not knowing much about Intercom my gut reaction is that it sounds a little counter some of the main goals of the Anytype app.

I’m personally cool with whatever but hope there is a way to 100% disable it when not in use.

2 Likes

When I’m using Anytype, I’m expecting it to use HTTP for updates and IPFS for syncing notes.

I don’t want it to load proprietary dynamic JS crap for support I don’t need.

Maybe an in-app link to Intercom would be more appropriate?

6 Likes

I’d personally prefer a chat/support button which opens my default browser.

If you think a built-in solution is the way to go, please provide an option to disable it.

1 Like

Oh boy, well… I have some thoughts on this. Sorry for the rant, but here we go… :stuck_out_tongue_closed_eyes:

I want to hear a seriously good case for why in-app chat - or any additional chat - is a good idea at all. There are already forum threads that go unanswered here for days, sometimes as much as a week (I’m fairly sure I can even find threads that have never been answered). There are Telegram, Discord, and Reddit posts that also go unanswered, or are answered largely by other testers or general community members. It’s fine and great for the community to help out, and I don’t begrudge the Anytype team their success and resulting busyness, nor do I want to “call out” anyone. The increasing levels of interaction in many of these communities is good in many ways, and a sign of success! My point is: the team is already appearing to have some difficulty keeping up with the existing volume of discussion.

Adding another channel of any kind seems problematic in my view, much less one that is entirely 1:1, which means that no one else but the single user being supported in that instance can actually receive any benefit. This compares poorly with literally every other existing contact method the team has, besides email and DMs.

In Telegram and Discord everyone else can see what is said and, in many cases, it is quite likely that someone may benefit from a response given to another person. I have seen this many times myself, e.g. someone will ask about getting alpha access, a community member will respond, and 1 or more other people (besides question asker) will pipe up then saying “Thanks, I was wondering that too!”. This kind of thing cannot happen with Intercom or any private, 1:1 interaction method, and for that reason it inherently uses more staff time, time which we can see is already limited. And of course you cannot control/limit what people will use Intercom to ask you. You can add FAQ answers based on question keywords, which can be semi-effective, but you could do something just as effective for e.g. “How do I get alpha access?” questions with Telegram and Discord bots, and still avoid being inundated with a bunch of private messages that demand limited staff time.

The advantages of Discord and Telegram of in-public discussion are shared by the forums, and there are even more benefits here due to greater organization with Topics, better Quoting functions, better searchability and SEO (when the forums become public, answers to many previous questions could be immediately accessible), and extra possible functions like marking a particular response as the “Solution”.

Of course you can partially address some of these downsides by using even more staff time to try to turn 1:1 interactions into e.g. knowledgebase articles, FAQs, etc. but it’s a manual process. It’s not efficient and if you don’t have time for every forum thread, you don’t have time for adding 1:1 chat, and you certainly don’t have time for turning those chats into FAQ articles, etc.

If the team really wants to use 1:1 chat, in my view it should only be used for very particular direct support situations where you need to go back and forth in real time with a user having an issue or with a more complicated and specific question. In that sense it should probably be invite-only in some way, e.g. “We need to work directly with you on this issue. I’ve sent you an invite to schedule a real time chat with a team member”. It should, in my view, be in some way “high barrier to entry” to get a direct contact with a team member in real time because team member time is valuable and quite finite!

I would agree that moving away from Telegram DMs would be ideal for real time support (I’m assuming that’s part of the goal here), mainly because it allows for a more interchangeable “agent”-based approach, i.e. anyone can take incoming support requests, rather than DMs that go to individual team members. Intercom and other systems also have much better ticket-style issue handling and tracking systems, which should help vs. Telegram or Discord DMs. But again that is only in comparison to other 1:1 real time methods, which I think should be minimized to only necessary situations anyway.

And all that is aside from the very real and well-covered privacy concerns already expressed here and in Discord, if not elsewhere. If you try to work around those issues, then you likely have to increase complexity and thus time somewhere else, e.g. providing two app builds, one with Intercom, one without. All for a method of interaction which it seems questionable the team can even support well or, if it does, then it seems it must inevitably be at the expense of every other existing and already popular contact method (2500 Telegram group members, 450 Discord members, 1200 Redditors, etc.).

That’s my strongly opinionated 2 cents dollars :grinning_face_with_smiling_eyes: from covering a software support desk full-time across multiple interaction channels for 10 years.

I dunno, am I alone in these concerns??

4 Likes

You are by no means alone with these concerns! I’m relatively new to this community so I’m not quite comfortable yet with posting so strongly. You have a very persuasive argument here for communication channels to be simplified instead of broadened. I personally want to keep up with Anytype dev and have already run into the issue of there being too much chatter to keep up with. If I want to keep current with all the news I have to watch telegram, Discord and the forum (which is a lot).

+1 to there being too much already, Adding new communication channels can easily turn into a time sink. There is already TONS of people constantly asking for alpha access.

5 Likes

What makes you say that? We’ve been using it for a while and for the purpose of self-hosted with open source code and lightweight, has been very stable.

Certainly, i’d not be concerned if that was used but not a fan of Intercom and data being stored by an unknown* third party.

*I say unknown as a non-contracted other entity who I don’t have any data retention agreement with etc.

1 Like

In general, I’m in agreement with @Oshyan on this. I’d add the following thoughts (just to prove I can also write long posts :smiley: ):

I’ve had a lot of experience in setting up support channels for new software (and process) implementations and I’ve learned some hard lessons.

    1. It’s critically important to distinguish user-to-user support and discussion from formal support provision, and equally critical to make it clear to customers what the difference is. People need to know where they can go to get specific types of support. Commonly:
  • Formal support group to report bugs, get emergency assistance

  • User forum to exchange questions & answers and as a repository for frequently asked questions/common issues

  • Group chat for, well, unstructured chat. Users need to be actively discouraged from using group chat as their primary support channel. They get annoyed when they can’t find a simple way to get an answer and that splashes back onto the product and the team.

    1. 121 chat is a time- and resource-sink. It expands to occupy at least 20% more than the actual time and resource available, at the cost of other important work. It’s solely a last resort for the user who has an unusual and intractable issue that can’t be solved without handholding. In my implementations, we’ve reserved it for those cases and it’s allocated on a managed basis by the support team management.
    1. I would always advocate Discourse-type forums for user-to-user support. They’re easy to understand and use and it’s easy (or should be!) to find posts about your question or problem. Anytype support should contribute to those discussions, but not as alternative to some kind of formal issue reporting.

Formal support needs a formal system, and I don’t think 121 chat is it: it’s expensive and inefficient and invisible. You could make it an extra-cost option, or offer it to enterprise users (but either of those entails costs and risks of their own). But I absolutely don’t think it should be a one-click, in-app feature. I think you’ll be drowned by the number of requests and (even worse) by repetition of the same questions and answers.

  • You might want to provide 121 chat facilities to a core group of testers (by core, I mean small), but even then, I think it’s too inefficient. Far better to give them a private group chat.

  • Group chat (Discord, Telegram etc) is awful for large scale user support. High volumes of unstructured posts with limited ability to sort and filter are a nightmare. While Anytype is in alpha/beta, it might look reasonable to rely on group chat, but I’d expect that to become unsustainable by the time the waitlist has been onboarded. I’d much rather see these forums become the centre of gravity (there would need to be some upgrade of features for that to work)

FWIW, Roam Research is an object lesson how not to do this (IMVSHO - In My Very Strongly Held Opinion) and I’d be very keen for the Anytype to team to avoid some of their mistakes. (Summary: Roam currently uses Twitter, Discord, GitHub, Reddit, Slack, its own Roam graph, and has deprecated Discourse after moving to it from some other forum service whose name I can’t remember). Users can use any or all of those channels for support and may or may not get a response which may or may not be from the Roam team. It’s a mess. They’ve been charging users $15 per month since last June and they still haven’t sorted it out. As far as I can figure out, Twitter is still the primary channel, which makes no sense to me.

In short, you can spread the social discussions as wide as you like, but please please please confine actual support to a small number of defined channels each with defined uses.

4 Likes

@ThatGuy Glad to hear your perspective as someone who has also dealt directly with these issues and considerations in past work! I of course agree almost entirely with all you’ve said. Especially with Roam as a great counter-example. I was a part of the discussion around Slack being chosen in favor of Discourse, and I never really say any clear, compelling reasons for it, it just appeared to be an inertia thing. Slack is demonstrably terrible for this kind of thing, far worse than Discord, Telegram, etc. even, so it was all the more troubling that it ended up being the winning solution. I think it was because the had an existing Slack->Roam connection and they really wanted Roam to end up being the “single source of truth”. But in practice it works terribly for actually surfacing useful information, much less adding to or otherwise engaging with it. Anyway, enough about that. I think Obsidian is a great counter-example, which I’ve mentioned elsewhere before.

Just one small point I want to clarify, which is when you say:

What in your mind is a good choice for the “more formal issue reporting”? It seems you are saying not to use Discourse for this, and if I understand that right, is it because you feel a forum is not well setup to do formal issue reporting and tracking? Do you think those limitations can be overcome with plugins and integrations? (I do, just curious if you agree)

The thing about formalized issue trackers is they mostly are also invisible to the other users (besides reporter, and sometimes even to the reporting user!). I feel like the benefits of forums can be great for issue reporting and discussion as well, provided you can minimize the limitations (which, again, I think you can).

Currently I am pretty into Fibery’s integration with Discourse, which makes it possible to both maintain open user engagement and visibility of issues, but also do sophisticated internal engagement, prioritization, etc. in the private dev team system (e.g. you can link a Discourse thread to an issue or feature request, epic, etc., you can highlight text and get backlinks/references, you can assign people to a Discourse topic, you can aggregate feedback scores for prioritization, etc).

Why?

As a user, I want to be able to write a forum post and have either AnyType employees or random users reply. It is actually a better support experience to allow the community to help get tickets (or forum posts) answered faster. The only exception is for account access issues which probably doesn’t apply to AnyType: because of all the privacy, they can’t give us back access to our accounts anyway.

I do agree with Oshyan on the too-many-support-channels problem, and I’d rather have one place to go with my issues (I pick here on Discourse).

1 Like

@Narvey I tend to agree. As long as it is clear when staff is replying vs. regular users (and here in Flarum I would argue it is not necessarily as clear as it could be), then I think it is generally advantageous to allow anyone to respond to issue reports. We have seen the potential benefits here on this very forum, with some people having their issue resolved by other users, or at least having it confirmed or more information provided. So far I have not seen a real downside to it here (nor in my past experience on other forums). I understand the desire to limit it in theory, I just think practically speaking it’s more useful not to.

Wasn’t there an embedded matrix chat for websites? Maybe that could work.

@bbigras for websites, there was a chat option that has now been removed. The team is looking for something that could integrate with the app during the testing phase to allow for easier and faster feedback.

@div3xi This one?

https://www.safesupport.chat/

https://github.com/arnav-t/riot-embedded

@bbigras What how are they going to implement https://www.safesupport.chat/ ?

@div3xi is anytype using react native? Maybe they can adapt it. It’s js.

@bbigras There are numerous open source options that could work and avoid most privacy issues. The question remains whether it is a good and useful idea to have in the app or not, or to have 1:1 chat at all. Most of my concerns above remain, regardless of the specific tool that might be chosen.

2 Likes

As long as it’s in a sandboxed context it’s probably fine, although obviously something self hosted such as safe support chat would be preferable, also if you implement it you’d need to add an option to disable it.