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!
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!
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.
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
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?
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!
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.
There are a ton of free live chat clients out there. What makes this one stand out?
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 :-)
I'm an Intercom customer and presumably also a potential Smooch customer, and I have no idea what this means.
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.
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 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?
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!
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.)
