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.
Congrats on the launch. As a fellow Ruby/Rails developer I love seeing great open-source Ruby/Rails apps in a world where everyone seems to be trending to what's "sexy" now instead of what's tired and true.
You'll never make everyone happy... For me the fact that it's RoR as opposed to, say Go or Elixir is a big turn off, because I know it will be slow and eat up lots of RAM.
For me tried and true would be Java.
Amazing to see your vision coming to life by open sourcing the code and getting so many contributors! No small feat. And great to see the project is being done in Rails. I’ve spent hours looking for a a good product in this space for our company so will definitely give this a try. Two questions - do you have a way to author FAQs and is email an accepted channel?
Thanks for the kind words. Please see my response below.
> 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.
Congratulations on the release. Wish you all the best with it, and will not hesitate to recommend it … but first, email 100% has to be supported. Should be as good as Intercom's user-facing email flow.
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.
Chatwoot Co-Founder here:
Thanks a lot for the support.
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.
There are a couple of things which I can tell, most important is that we were naive and we were not patient enough to see the project grow organically and reach the users and find its USP. We wanted instant gratification which is not always available in the startup world.
omg I love you. I probably wont switch til you have a hosted version where I can pay you, sorry. Maybe you can launch one on heroku for me as a beta user and I'll pay you?
Chatwoot Co-founder here:
Thanks a lot for the support. A hosted version will be up by end of this month. Meanwhile, you can deploy the repo easily to heroku. Will be happy to assist if you face any issues.
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!
Too bad there is no way to make a blocklist to block all freeloaders from visiting websites.
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.
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.
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.
>>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 only because they are being subsidized by those who actually pay
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.
>>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
Freeloaders already paid for the internet connection.
I don't see how it's freeloading to not want to interact with a stupid popup chat robot. I will never, ever, use your stupid chat popup. Ever. So if I'm blocking it, you are losing nothing. Nothing changes for you when I block all your marketing tools, because I will not engage. In fact I actively disengage if I see any of them, so by blocking them, you actually stand a chance of me sticking around on whatever your service is, and unless your service is providing chat robot popups, you probably then stand a better chance of me actually making you money.
> the same people who complain...don't stop using the website itself
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.
Chatwoot Co-Founder here:
Thanks a lot for the support.
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
Having worked in this field for a while, you should look at tiered and tagged assignment. E.g. escalation tiers / priority assignment and assignment by browser language / geo up. From what I recall these were important as you look at supporting large organisations. Customisability (design) and pre-chat forms were also headline features.
Email channels and pre-ticket forms are dealbreakers for being a Zendesk replacement. I can live without a lot of ZD's features (and be happier for it) but those two are table stakes for me. I could see this being a replacement for Intercom, but Intercom isn't a fit for us either.
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).
Yeah agreed, KB integration was another big one, as well as shortcuts when you have agents who do 3-4 chats at the same time. In fact the ability to define agent capacity individually and by role to begin with is important.
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.
Great work. While on the topic, I believe everything ranging from Uber to Google can be replaced by an open source alternatives. There will be some cons but overall lots of benefits.
We have been using Zammad for over a year and are extremely satisfied! The developers have programmed OTRS and know what they are doing. The only thing we missed was a tool that asks the user if he was satisfied after a completed support ticket. Thanks to Zammad's API, we were able to easily program this ourselves.
The least interesting part of intercom at this point is the chatbox itself.
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)
This is great! I'm using Intercom, but I know it's going to get very expensive over the next few years, so I will keep an eye on this project.
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.
As a general thought, depending on your git hosting needs Gitea may be suitable instead of GitLab.
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.
I’m glad to see open-source alternatives for this! Without judging how good or bad this technically is, I’m happy to see the devs made it visually appealing. Good job.
My only complaint is the docs page. If I use Safari on iOS I can only see this [1] and nothing is clickable besides the menu, which offers a link to the same place.
Chatwoot Co-founder here:
Thanks a lot for the support. A couple of our devs come with a design background as well, so aesthetics and UX is also something we take great pride in.
Also thanks for bringing that bug up, we are working on fixing that.
Thanks :) We started off with a theme which is using Bootstrap and the illustrations are created by mixing humaaans.com characters with undraw.co illustrations. The font we used is paid font, so we couldn't make the repo open. Tech stack is React with Gatsby hosted on Netlify.
Nithin, Co-founder of chatwoot here. We're so happy that ChatWoot will help you and 1000 other people who are spending a ton on these tools :)
Also Feedbacks like this motivates and drives us. Keep supporting :)
Founder here,
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.
Congrats on the launch. As a fellow Ruby/Rails developer I love seeing great open-source Ruby/Rails apps in a world where everyone seems to be trending to what's "sexy" now instead of what's tired and true.
Remember when folks called RoR "sexy" and CGI tried and true? Or swap any two nearly similar stacks.
Stack don't matter, it's not the wand, it's the wizard and time makes fools of us all.
https://www.youtube.com/watch?v=YZeZsZEEpno These two actually made me hate the language/framework which is why I never gave it a shot.
What's that last jar supposed to represent?
Looks like gasoline/petrol which is sometimes used by people to huff (inhale) to get high.
The whole "serverless" trend feels (felt? Did the fad die out?) like coming full circle back to (Fast)CGI.
interesting spin on 'tried and true.' also works and made me smile.
unless it was a typo.
You'll never make everyone happy... For me the fact that it's RoR as opposed to, say Go or Elixir is a big turn off, because I know it will be slow and eat up lots of RAM. For me tried and true would be Java.
Nice project! Curious: has any organization started using Chatwoot to provide customer support?
There are no other organizations which are using the project other than us. We use it on our homepage chatwoot.com and for our Facebook pages.
That will change soon. :) Awesome project!
Chatwoot Co-founder here: Do let us know if you face any issues. Will be glad to help.
Would like to let you know the hamburger menu currently doesn't work on mobile (clicking it does nothing)
Hey, thanks for letting me know. I will fix it soon :) Looks like I forgot to add the action on the hamburger button.
Related, the chat window that pops up on android is off screen about 15 to 20% but still workable.
I am very familiar with Intercom, and this looks comparable at first glance. Nice start.
Amazing to see your vision coming to life by open sourcing the code and getting so many contributors! No small feat. And great to see the project is being done in Rails. I’ve spent hours looking for a a good product in this space for our company so will definitely give this a try. Two questions - do you have a way to author FAQs and is email an accepted channel?
Thanks and can’t wait to see Chatwoot grow.
Thanks for the kind words. Please see my response below.
> 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.
Congratulations on the release. Wish you all the best with it, and will not hesitate to recommend it … but first, email 100% has to be supported. Should be as good as Intercom's user-facing email flow.
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.
Chatwoot Co-Founder here: Thanks a lot for the support.
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.
What were the reasons for failure? It would be great to learn more about your experience.
There are a couple of things which I can tell, most important is that we were naive and we were not patient enough to see the project grow organically and reach the users and find its USP. We wanted instant gratification which is not always available in the startup world.
A lot of first-time entrepreneurs need to listen to this comment.
Good job. I hope it gets traction. I've scheduled it to be featured on the homepage of SaaSHub for next Monday.
Chatwoot Co-Founder here: Just saw that its up on SaasHub. thanks a lot for featuring.
No worries. Just keep up the good work.
I'd also suggest, asking some of your users to leave you a review on SH.
Nice job! Have you done any load testing on it? Curious how much server to buy to run an instance with some usage.
Chatwoot Co-founder here: We haven't done a full-scale load testing yet. But we were able to handle the HN traffic using Heroku's free tier.
omg I love you. I probably wont switch til you have a hosted version where I can pay you, sorry. Maybe you can launch one on heroku for me as a beta user and I'll pay you?
Chatwoot Co-founder here: Thanks a lot for the support. A hosted version will be up by end of this month. Meanwhile, you can deploy the repo easily to heroku. Will be happy to assist if you face any issues.
A full demo or feature list would be nice. For comparison to other options out there.
Chatwoot Co-Founder here: We are working on the feature comparison and roadmap pages. It will be up on the website in a day or two.
just record a 1 to 2 minute demo of you walking thru standard use cases. it will only take a couple hours and is well worth it.
> It failed due to a couple of obvious reasons. We built on Vue.js and Rails
I read it with a comma instead of fullstop between the sentences :D
Haha! I did the exact same thing I was wondering what was wrong with either of those stacks
> It failed due to a couple of obvious reasons.
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!
Here's a blocklist for all these super annoying chat widgets: https://raw.githubusercontent.com/bcye/Hello-Goodbye/master/...
You can import this into uBlock origin so you never have to see these things again.
Too bad there is no way to make a blocklist to block all freeloaders from visiting websites.
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.
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.
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.
>>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 only because they are being subsidized by those who actually pay
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.
>>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
Freeloaders already paid for the internet connection.
> That's because you already paid for it
This is not true for free over-the-air television.
I don't see how it's freeloading to not want to interact with a stupid popup chat robot. I will never, ever, use your stupid chat popup. Ever. So if I'm blocking it, you are losing nothing. Nothing changes for you when I block all your marketing tools, because I will not engage. In fact I actively disengage if I see any of them, so by blocking them, you actually stand a chance of me sticking around on whatever your service is, and unless your service is providing chat robot popups, you probably then stand a better chance of me actually making you money.
There is. It's called a paywall. More websites should use them.
> the same people who complain...don't stop using the website itself
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.
Thanks for this; it'll keep my cookie-consent-, overlay-, and dickbar-blocking filters company.
Congrats on pivoting this to open.
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!
Chatwoot Co-Founder here: Thanks a lot for the support.
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
Having worked in this field for a while, you should look at tiered and tagged assignment. E.g. escalation tiers / priority assignment and assignment by browser language / geo up. From what I recall these were important as you look at supporting large organisations. Customisability (design) and pre-chat forms were also headline features.
Email channels and pre-ticket forms are dealbreakers for being a Zendesk replacement. I can live without a lot of ZD's features (and be happier for it) but those two are table stakes for me. I could see this being a replacement for Intercom, but Intercom isn't a fit for us either.
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).
Yeah agreed, KB integration was another big one, as well as shortcuts when you have agents who do 3-4 chats at the same time. In fact the ability to define agent capacity individually and by role to begin with is important.
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.
Co-Founder here: These are all great suggestions. We are reworking our roadmap based on the feedback from HN. Thanks a lot for these.
Great work. While on the topic, I believe everything ranging from Uber to Google can be replaced by an open source alternatives. There will be some cons but overall lots of benefits.
I agree. I assume having a hosted version of tools like CRM or support desk would help in getting better at maintaining the privacy of the customers.
This is great. Intercom’s pricing is outrageous for small startups so I could this getting traction.
It's $50 per month for all their products in their new program... This isn't insane but is still pricey when you're in an MVP mode.
What new program?
https://www.intercom.com/early-stage
Another great open source helpdesk in this space is Zammad https://github.com/zammad/zammad
We have been using Zammad for over a year and are extremely satisfied! The developers have programmed OTRS and know what they are doing. The only thing we missed was a tool that asks the user if he was satisfied after a completed support ticket. Thanks to Zammad's API, we were able to easily program this ourselves.
The least interesting part of intercom at this point is the chatbox itself.
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)
Do you think that holds true for both sales and support?
This is great! I'm using Intercom, but I know it's going to get very expensive over the next few years, so I will keep an eye on this project.
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.
As a general thought, depending on your git hosting needs Gitea may be suitable instead of GitLab.
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.
Except for mattermost, I’ve run all those in a Kubernetes cluster. Good stuff.
On the own you’re own data theme, I would also throw in metabase, mautic & zammad.
Look into Zulip before you settle on Mattermost. I've used both, and vastly prefer Zulip's threaded model.
I’m glad to see open-source alternatives for this! Without judging how good or bad this technically is, I’m happy to see the devs made it visually appealing. Good job.
My only complaint is the docs page. If I use Safari on iOS I can only see this [1] and nothing is clickable besides the menu, which offers a link to the same place.
[1] https://imgur.com/aD1bJh3
Chatwoot Co-founder here: Thanks a lot for the support. A couple of our devs come with a design background as well, so aesthetics and UX is also something we take great pride in.
Also thanks for bringing that bug up, we are working on fixing that.
I love the super clean design of your main website. Is that based off a template or made from scratch using UI library?
Yea it's really nice. I looked through the Github repo could couldn't figure out what library they used.
Would love to know what css/ui they are using.
Thanks :) We started off with a theme which is using Bootstrap and the illustrations are created by mixing humaaans.com characters with undraw.co illustrations. The font we used is paid font, so we couldn't make the repo open. Tech stack is React with Gatsby hosted on Netlify.
This looks awesome, will watch for updates. I run a small nonprofit and we spend around 350/m on support services, would love to cut this cost!
Nithin, Co-founder of chatwoot here. We're so happy that ChatWoot will help you and 1000 other people who are spending a ton on these tools :) Also Feedbacks like this motivates and drives us. Keep supporting :)
This being only chat, what about email support?
Chatwoot Co-Founder here: We are still working on email support. The feature is halfway done. It should be ready by the end of this month.
progressing here on : https://github.com/chatwoot/chatwoot/tree/epic-email-inbox
Very nice to have more open source choice. Is there a flow builder with GUI included for bots?
Nithin co-founder here, Thanks a lot for the feedback :) At present we don't support bots, instead we have multiple agent based support solution.
I was hooked until I saw `rake`, at which point I was triggered _big time_. I'm just imagining the memory consumption of this behemoth.