Show HN: Open Source alternative to services like Intercom.io and Smooch
github.comThe hardest part is not the client and the server...but the CRM (the Intercom part). Here's something a lot of us would use - we want to bring our own socket API (for example pure websocket, xmpp or something like Pusher.com ) and connect it to a full fledged Intercom-like tool.
This is the "Gitlab for Intercom". The problem that happens is that people usually don't want to rip out their client side messaging SDK, especially if you have a mobile app.
I am personally looking to pay for something like this (we use Pusher.com internally).
Are you focusing on the socket server or the CRM application (like Intercom) ? Because the socket server part is a don't care for everyone. Pusher or Firebase is super cheap. It's the CRM that's tricky. Smooch is one end of the spectrum and it focuses on integration with other tools (helpscout,etc) while Intercom is obviously a CRM. I don't think you'll be able to build both.
If you can build this out with excellent featureset like Intercom and can integrate with something like Pusher (and not lock to your own server), I'm gonna throw money at you!
Just want to echo, I’ve recommended intercom.io for a company I was on the board of. It was a huge boon to them. The chat was 5% or less of the value. The analytics… tieing messaging based on actions… the visibility into active/growing, influencers/detractors vs passive/slipping away and guided processes for new features: (show this set of messaging to my feature flag’d customers who have access to beta functionality)… thats the value of intercom.
Wow, this is incredibly valuable feedback, thank you so much! We appreciate your candor (and encouragement!)
You're right in that the socket server is fairly easy to pull in using other tooling. Our focus at the moment is to just build a stable set of pieces that you can use to interact with your website visitor. The operator transports are where things will get interesting, connecting to other tools, etc. This is where connecting things like Pusher will shine, we hope.
Thanks again for the feedback!
The gitlab-for-intercom has genuine value there, so if I were you, I would just use a third party transport and build a killer product there.
Build something I ^H^H people want ;)
IMHO the rest can come later. Just my $0.02 . Excited to see what you come up with.
Hey all,
One of the creators, this is the first project we've taken from inception to open source, and are working towards building a hosted service [0]. A big motivator for building it was the high costs associated with competitors like Intercom.io and Smooch
It mainly comprises of 3 code bases, the server[1], the client[2] and then an application[3] to speak to the client.
As always would love to hear feedback, good and bad! Also if you have any questions let me know :)
[0]: https://minimal.chat [1]: https://github.com/minimalchat/daemon [2]: https://github.com/minimalchat/client [3]: https://github.com/minimalchat/operator-app
Glad to see one more project, can already see some bugs :) would love to contribute. Shameless plug http://raspchat.com/ I have done similar hobby project which runs server on Raspberry Pi at my work place and it can handle quite some load. Last time it got posted on 4chan it was spammed by ~5K connections constantly pounding spam messages, but it handled traffic well (it did slow the whole thing down to it's knees).
Nice! please make an issue for the bugs!! We've done some initial load testing, and are super pleased with using go channels as the server layer medium.
Hey! Nice! This project might be just the thing for our open source project's homepage, to allow non-technical folks to engage with us easiest!
It feels like it would be really beneficial for it to work with matterbridge (https://github.com/42wim/matterbridge), then people could pipe it into whichever tool they prefer.
Any plans to have it speak an established protocol, like xmpp?
Thanks ^_^ I havent heard of matterbridge before, so I definitely will star that and take a peak, looks cool
We've thought about working with xmpp because it would allow us to cover a lot of things people use to connect with, and plan on building out an operator (our speak for the other end of a web visitor's conversation) for it!
This isn't an alternative to Intercom. This is an alternative to Intercom's live chat feature. This is only a very small portion of the value you get from using Intercom.
I think an open source alternative to Intercom would be super compelling, just, this isn't it. You're missing the CRM, email automation, events, help center, etc.
Wouldn't this be a lot more like a replacement for services like Live Chat? Because I definitely would not be paying as much as I am for intercom if I was only using the live chat feature. Their integrated abilities to categorize users and program and schedule onboarding messages as well auto suggested help articles are what makes it worth the price.
There are a ton of free live chat clients out there. What makes this one stand out?
Hey everybody! Co-founder of Smooch.io here.
Really like what what you've built here, a lightweight and open source web messaging system is definitely a useful component that a lot of websites could leverage.
Wanted to clear up a common misconception that Smooch.io and Intercom are solving the same market need. Although Smooch began life as a mobile-focussed Intercom, as we've learned about our industry we've pivoted to address a need lower down in the stack.
Essentially, we've discovered that the biggest impediment to having more businesses taking advantage of messaging as a channel is the lack of software that can provide rich access to the channels coupled with a powerful CRM and deep integration capabilities. Most businesses didn't want to rip and replace their current CRM and contact center investments, nor did they want to invest in connector middleware. They expected messaging to be a first-class feature of the products they already use and have trained their support teams on.
That's why we now focus on selling our technology as an API that can be used by software vendors to add a complete messaging, customer profile and conversation orchestration stack to their products. It's been adopted by some of the biggest vendors in the customer-service space because it helps them focus on the differentiated features (like workflow) that help them succeed in market, while ensuring they can trust the "plumbing" to an enterprise-grade, highly reliable platform like Smooch.
So we don't view Minimalchat as an alternative to Smooch. We view it as another messaging channel to which Smooch can allow a business to connect. Similarly, we don't view Intercom as an alternative to Smooch - we view it as a (prospective) customer.
Finally, just noticed that you're in Toronto. If you like building Minimalchat and care about messaging - we're hiring: https://smooch.io/about/#op-196776-software-developer :-)
> Essentially, we've discovered that the biggest impediment to having more businesses taking advantage of messaging as a channel is the lack of software that can provide rich access to the channels coupled with a powerful CRM and deep integration capabilities.
I'm an Intercom customer and presumably also a potential Smooch customer, and I have no idea what this means.
Thanks for asking for the clarification Eran. Definitely could use some here!
Essentially, we discovered that while in certain segments (like SaaS apps), using messaging to communicate with customers is commonplace, greatly due to companies like Intercom that provide great tools for these types of companies to successfully communicate.
However, the tools Intercom provides just don't exist in a format that works for most other businesses who use anything from traditional helpdesk software like Zendesk to full-blown contact center suites like those provided by Genesys and Oracle.
Since we believe in a future where every business is available over messaging channels, we needed to ensure that the systems they use can provide access to these channels. We had two choices:
1. Build middleware that a business could purchase that would allow them to connect a messaging channel (like a web messenger, Facebook or WeChat) to their existing software. 2. Open up our platform so that incumbent software providers could adopt it to add messaging capabilities to their product.
For a host of reasons, we quickly determined that option 2 was the best path towards making sure that a wide variety of businesses can communicate with users over messaging. We've been hard at work making sure that this happens ever since.
Hey, really appreciate and honored you took the time to write a comment!
I think that our concept of operator transports and your API technology definitely have some parallels. We don't plan on marketing towards enterprise as we generally believe that they have money to burn on large sophisticated products like Smooch (or build it themselves).
We're taking it one step at a time, first build a good base, then figure out where to head from there. Again really appreciate you taking the time to comment and your feedback!
I'd be more interested in an open source user analytics package that shows which users are online, etc. that you can find in Intercom.
Nifty start. The need for a hosted service like this is more for secure apps where third-party services may have some privacy implications.
I think the default UI needs a little more work. Intercom also lets you email users based on certain triggers, is there an email integration that you are building towards?
Edit: Just curious, what made you code the server in Go?
Thats a good point re: secure apps/third party services. we also wanted to run a hosted service for the lazy who may not want to bother learning how to run each of the pieces ;)
Thanks for the feedback too, in complete honesty, it was a combination of we were interested in the language, and overheard it was good with concurrency... that was enough for us to give it a shot.
Edit: Also apologies for not answering your question re: email integration, its going to be one of the first major integrations we do!
Nice work! Looks tempting... until you realise you need to integrate your service with a whole heap of other platforms. Or build scale. Classic Build vs Buy — are you building a core capability in your product, or are there more important things you should be focusing on?
Thanks for the feedback :) Our initial "core" has been surrounding the live chat, but our approach has been to build it into many separate pieces. This allows us to focus on what we think are the major integration points next. As well as ensure that the things that need to scale well, do, like our socket server.
Hi @mihok and everyone, Co-founder of Broid here. Have you had the chance to look at our repo (https://github.com/broidHQ/integrations) ? @ Broid, we believe in democratizing messaging and we do so by providing an open standard using the W3C AS2 schema.
We are currently supporting more than 20 Messaging Platforms as well as providing a Web Messenger (website & mobile) that has all the best conversational features: carousels, cards, quickreplies, geolocation etc..
I would be happy to discuss with you about minimalchat and see how the Broid community or the team can help you.
(We are looking for contributors to be part of the team.)
Admirable effort...but why not focus on the front-end/app - the CRM side of things - and simply develop on the shoulder of giants? By this i mean, maybe consider using an existing, underlying messaging platform like matrix.org. Visit https://matrix.org and scroll down to the "What is this for?" section, to see what i mean. And, as others noted, this would allow you to focus on the CRM portion, which is what end-users and clients would value more (read: pay you money). Just a thought.
Looks great! Maybe add more docs so it's easier to setup.
Thanks for the feedback! Its so easy to get tunnel vision on ease of setup since we've been doing it for so long, so we'll definitely improve the setup docs!