The 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.<p>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.<p>I am personally looking to pay for something like this (we use Pusher.com internally).<p>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.<p>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!
Hey all,<p>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<p>It mainly comprises of 3 code bases, the server[1], the client[2] and then an application[3] to speak to the client.<p>As always would love to hear feedback, good and bad! Also if you have any questions let me know :)<p>[0]: <a href="https://minimal.chat" rel="nofollow">https://minimal.chat</a>
[1]: <a href="https://github.com/minimalchat/daemon" rel="nofollow">https://github.com/minimalchat/daemon</a>
[2]: <a href="https://github.com/minimalchat/client" rel="nofollow">https://github.com/minimalchat/client</a>
[3]: <a href="https://github.com/minimalchat/operator-app" rel="nofollow">https://github.com/minimalchat/operator-app</a>
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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>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.<p>Finally, just noticed that you're in Toronto. If you like building Minimalchat and care about messaging - we're hiring: <a href="https://smooch.io/about/#op-196776-software-developer" rel="nofollow">https://smooch.io/about/#op-196776-software-developer</a> :-)
Nifty start. The need for a hosted service like this is more for secure apps where third-party services may have some privacy implications.<p>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?<p>Edit: Just curious, what made you code the server in Go?
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?
Hi @mihok and everyone,
Co-founder of Broid here. Have you had the chance to look at our repo (<a href="https://github.com/broidHQ/integrations" rel="nofollow">https://github.com/broidHQ/integrations</a>) ?
@ Broid, we believe in democratizing messaging and we do so by providing an open standard using the W3C AS2 schema.<p>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..<p>I would be happy to discuss with you about minimalchat and see how the Broid community or the team can help you.<p>(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 <a href="https://matrix.org" rel="nofollow">https://matrix.org</a> 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.