Chatwoot is a customer support tool for instant messaging channels which can help businesses provide exceptional customer support through their websites or social media channels.
This was a product we started building in 2017. It failed due to a couple of obvious reasons. We built on Vue.js and Rails. It was in an inactive mode for around 1 and a half years. Recently we thought of putting it out instead of letting the code to rust. Our idea is to make it something like Gitlab/Mattermost where people can host their own version and we will provide a hosted version for people who don't want to self-host.
After we open-sourced, we received contributions from 30 developers all around the world.
We believe bots alone can't solve all the questions and there is no context. On the other hand, having agents alone for customer support won't scale as your business grows. We intend to build a bot+agent platform which is fully opensource and supports most of the social media channels, email and websites.
Stack don't matter, it's not the wand, it's the wizard and time makes fools of us all.
Would you mind elaborating? Would love to hear why. Seems like a good chat-focused alternative. Was the competition from Freskdesk too stiff (assuming you're based in Bangalore)?
Anyway congrats on breathing new life into the project!
I'd also suggest, asking some of your users to leave you a review on SH.
Thanks and can’t wait to see Chatwoot grow.
> do you have a way to author FAQs
Right now, we don't support it. We have FAQs and a documentation website in the pipeline.
> is email an accepted channel?
Honestly speaking, it is not completely done yet. Emails from support desk mail can be seen in the dashboard, but you cannot respond to it now from our dashboard. Hopefully, we would be able to complete it sooner.
Email and twitter DMs are IMO more important for people looking for a support channel than "live agent" chat boxes. Live agent boxes are often adblocked and can't ever be the sole point of contact for a company that cares about having a support channel.
Totally agree. email is currently our top priority item and the development is halfway through. We are also actively working on twitter DM as a channel.
Stay posted for updates.
I am very familiar with Intercom, and this looks comparable at first glance. Nice start.
I read it with a comma instead of fullstop between the sentences :D
You can import this into uBlock origin so you never have to see these things again.
The person who actually owns anything at all (the website owner) is somehow expected to give everything for free to someone who doesn't own anything at all (the website visitor). Plus I have found that the same people who complain loudly on internet forums about chat widgets (and many similar marketing tools) don't stop using the website itself for the sake of their principles. Hilarious.
TV Broadcasters don’t get to force you to watch their ads, in fact skipping ads on broadcast tv is a big and legal market.
Furthermore, today’s ad blocking detection can be very good at detention, so there you go - you have your script. When sites detect my adblocking and nag me, I am more than happy to leave their shitty website and never come back.
Unfortunately, if this is actually true, then you are the exception which proves the rule. That's precisely why I call these people "freeloaders". If they actually stopped visiting my website and wasting my site's resources based on such principles, I would be ecstatic to see them leave.
>>TV Broadcasters don’t get to force you to watch their ads, in fact skipping ads on broadcast tv is a big and legal market.
That's because you already paid for it, and the payment was what allowed the content to even get created.
>>I don’t understand what you are saying. There has always existed straightforward methods of preventing “freeloaders” as you call them from accessing your content. If you don’t believe me, go to wsj.com and report back.
That's an interesting example, considering the number of times you see non-paywalled links here on HN.
Freeloaders exist only because they are being subsidized by those who actually pay. That's exactly why paywalled articles also have non-paywalled versions. If you don't believe me (that non-paywalled versions are subsidized by people who pay), just ask someone who produces the content and report back. Or better yet, ask the same person who produced the content how long they will keep producing content if no one paid for access. As the old saying goes, at some point, you run out of other people's money.
Freeloaders exist because someone wanted to give something for free.
If someone put something online to be viewed freely and then expects some kind of return on it is hypocritical in my opinion. Just trying to make freeloaders look bad for their own lack of action to put it behind a paywall.
> That's because you already paid for it
Freeloaders already paid for the internet connection.
This is not true for free over-the-air television.
We do stop using the website. Instead of using the website, we use tools like https://archive.is/ and the Wayback Machine to view less user-hostile snapshots of the website.
As an Intercom customer ( perhaps paying too much ), it would be very helpful to see a basic feature comparison table and ideally an in-progress roadmap so that I may assess the opportunity costs for a possible migration. And if not a matrix, at least a simple list of top-level features, which I could not find in the docs.
For me, "Alternative", is a very loaded word that comes with an expectation of comparing the current scope of features offered by the aforementioned paid apps.
Best of luck!
Totally get your concern about "Alternative". In terms of the scope of features, we are still behind many of the current market offerings. But we will be making some steady progress over the new couple of months.
Meanwhile, we are updating the website & repo with feature comparison and an in-progress roadmap. It should be up in a day or two
The stuff ZD and Intercom (and SFDC) are awful at, where there are opportunities for something else to swoop in: even partial Markdown support for incoming messages, integrations with third-party docs/KB sources, live queue dashboards/visualizations, toggling features based on different support plans, and facilitating handoffs for follow-the-sun support (multiple queues, defined regions/hours per queue, auto-reassigning active tickets across agents and queues, cleaner or richer ticket summarization options).
The ability to define different capacities for the same agent across different queues and how to aggregate that is also an advanced feature which is useful. E.g. I can take 3 in English or one in French and one in English. Or I can take 4 tier one tickets or 2 tier two tickets. Or I can do x tickets for customers on basic support but if I'm on with a customer who has priority... Etc
Queueing and assignment logic gets tricky because requirements can be vastly different across organisations. Hence why there are companies at the high end charging enterprise money.
Intercom at this point is / is moving towards a tool to reach your customers / specific audiences sitting atop your eventing system to Target specific users at the right time (where a single one of those avenues may be through the chat widget).
The realized the least interesting part of this all is the chatbox itself, what's more interesting is leveraging internal information towards a better customer experience (through chat or other messaging channels)
I'm thinking about starting to run my own tools instead of relying on third-party software, e.g.
* GitLab.com (free, ~$80/mo for CI) => Self-hosted GitLab
* Sentry.io (free) => Self-hosted Sentry
* Slack ($24/mo) => Mattermost
* Google Analytics (free) => Matomo
The main reason would be for GDPR, HIPAA compliance, SOC-2, and PCI certification.
I also don't think I would save any money by running these on AWS. I would probably need a few m5.xlarge instances, and it would cost about $150/mo per instance. And then I have to monitor and upgrade all of the software, debug any problems, etc.
So right now I don't have any big incentives to go down this road, but that might change once I'm ready to look into HIPAA compliance.
It doesn't have anywhere near the same amount of integrations, but if you just need something with a decent web interface (github like) and using the same fork/branch/PR/merge model, it'll work.
It's system requirements are much smaller than GitLab, and it's trivial to just leave running for months at a time with having to actively SysAdmin it. GitLab is more of an "enterprise" system with all the bells and whistles, requiring a correspondingly higher amount of resources and ongoing maintenance.
On the own you’re own data theme, I would also throw in metabase, mautic & zammad.
My only complaint is the docs page. If I use Safari on iOS I can only see this  and nothing is clickable besides the menu, which offers a link to the same place.
Also thanks for bringing that bug up, we are working on fixing that.
Would love to know what css/ui they are using.
progressing here on : https://github.com/chatwoot/chatwoot/tree/epic-email-inbox