Intelligent chat that makes your team communication twice as fast
chatgrape.com
chatgrape.com
The biggest problem for a potential customer of a new service like this is that there is a high probability that the service won't be around in two years. The cost of the service itself is almost irrelevant: the cost of switching to something else can be very high, especially if the customer has more than a dozen users.
That's why XMPP is so attractive, even though there aren't many features built on it: you can run your own server, on metal or a VM platform, you can buy service with a guarantee that someone can take it over smoothly if one business model fails.
I might not choose those exact words, but IMHO the fundamental issue this raises is something any SaaS company ought to be addressing in a transparent and up-front way these days if they want any credibility. Unfortunately, there aren't many who do yet.
That's surprisingly difficult. IMNSHO, most SaaS fails completely on this count, and my businesses use very few of the trendy services for exactly this reason. Of those we do use, every single one is either (a) convenient but expendable without compromising the business, or (b) both well established and having some form of legally binding statements along the lines below.
What I would ideally like to see in most cases would be a guarantee that if a service were to be taken down then its source code would be released with some form of open licence so that any service you relied on could reasonably easily be converted to self-hosting. Obviously this isn't worth much for services that are essentially proxies, such as most payment services, but it's sufficient for continuity in many cases.
Otherwise, as a minimum I'd like to see automated tools for exporting data in some open format so it can be transferred to an alternative platform where this is a reasonable possibility. Where there are non-trivial issues relating to data export, such as with PCI DSS for the various card payment services, I think the most plausible approximation would be a legally binding promise to help transfer the data to an alternative provider.
Obviously if a start-up fails suddenly then even legally actionable promises aren't going to be worth much if anything, which is why we won't rely on any SaaS from a new start-up for anything essential no matter what their terms say. However, properly worded guarantees would at least stop exit strategies like acqui-hire or sell-to-competitor-who-shuts-you-down from screwing the customer base.
One good example IMHO is MailChimp, which provides a straightforward mechanism for customers to back up all their important data, not just mailing lists but also things like e-mail templates and stats that normally live on the remote system.
Another one that seems reasonable is Stripe, which has explicit wording in its (UK) legal terms guaranteeing meaningful notice under fair conditions if they're going to terminate an account, and guaranteeing that they will facilitate transfer of card data to another payment service also under reasonable conditions if a merchant using their service decides to terminate.
I'm Felix, the CEO of ChatGrape.
That's a big pain point we also had with a lot of services. Not necessarily when they were gone, but simply when we decided to try something new, which is part of the SaaS-Game imho. We are currently working on a convenient XML-Export that allows you to easily extract your Users, public discussions, etc. (no private conversations tho) at any time. To make the switch between ChatGrape and other providers easier, we'll have an option to export the data as Hipchat-XMLs, as they are already widely supported by almost every service.
Expect this to be out within the next two months.
Cheers, F
I think the biggest reason for many modern chat services to disregard XMPP is, because they fear that most advanced users might resort to their Adiums & Pidgins and wont use their web-services or Apps at all, resulting in half of the customers not experiencing the UX or unique features and therefore the value.
We had a long discussion in the beginning of the project and decided to make our architecture XMPP-friendly, but release it later in the future, as we need our early adopters to use the system.
So the answer to XMPP is "Yes, but after we gathered enough feedback"
Oh, noes, that would be terrible. I cannot explain in words how much I loathe the Slack app and by extension how much I loathe their "UX experience and unique features."
Since my company just recently left HipChat for Slack, I think the odds of switching again this year are pretty slim, so I haven't evaluated your app. I just want to ensure that you have considered that a non-trivial portion of the engineering group of a company may want to resort to their Adiums.
And the notification is merely a red dot. Oh, you only want the red dot if you're at-mentioned or someone posts in your team's channel? Too bad.
If you just distribute your site's webpage as an app, you're phoning it in. And that is why I want a chat company to use XMPP so that I can use Adium to manage my interaction (or lack of it) with the chat service.
I'm glad you like Slack. I'm sure they're going to do well, given how many folks sing their praises.
For some of us if it's not FOSS it's not going to be used.
Think GMail for example. It's got full IMAP and POP3 support, and people who want to use a mail client are free to do so. If they do (and I assume many people do), then Google doesn't get to serve ads to them. But Google still gives you the freedom to choose. And they've succeeded in alluring even the nerdiest of people to their web app.
In short, let your users decide. Make your UI so awesome that they want to use it. Having XMPP support will actually draw many customers to your service, since it's something that not all competing services offer.
You and others made some very compelling points in regards of XMPP.
We learned a lot from this discussion and I'll soon write a post about the takeaways we got from this HN-Thread at our blog - http://blog.chatgrape.com/.
Thank you for your sophisticated feedback.
-f
One of the most time consuming things you can do is to diagnose, fix or work around issues in other applications that you don't control or even have source code access.
Maybe "Slack" for enterprise? For Law Firms? Where security is extremely important and they are willing to pay? Not just OTR and encrypted chat but stuff not even YOU can read, maybe self-hosted licensing or in-browser locked keys for encryption? /me is not an expert here but those seem like valuable features that I don't see in Slack or Flowdock.
[EDIT] When you have pre-existing competitors in a space, particularly a space focusing on developers, if you can't provide a feature that would compel (me) to switch (which I won't, I love Slack, unless you've got something amazing Slack doesn't) then you need to focus on a different target.
I've seen a lot of powerful tools for developers and software teams pop up but I almost NEVER see those similar tools being pushed hard for other types of teams. Like Law Firms. Or politics. Or R&D labs. Scientists. So many out there!!!!
MARKET
Good point. We have a strong competition in this area and are facing a marketing challenge in the US with the hugely successful launch of Slack (I think that Hipchat and Campfire are still bigger atm).
We are currently reworking the landing page, but this concept video might explain a little bit better what we are after: https://www.youtube.com/watch?v=hFJBadyrTmI&list=UUaBvfEGLT1...
We make all company data available right as you type. The time you are switching back and forth between browser tabs to search for issues or appointments is a huge waste of time and - more relevant the bigger your team gets - of money.
SECURITY
> Not just OTR and encrypted chat but stuff not even YOU can read
We are currently working on an encrypted solution for OTR-Conversations that - thanks to WebRTC - uses p2p-connections and uses your wifi, if you are in the same office. This allows you to communicate internally with us only providing the client. This isn't as secure as an on-premise solution (we are working on it, but this will def. take a little more time), but it's a good way of giving customers the advantages of cloud software with an optional switch for an on-premise-like behavior.
MARKETING STATEMENT
> makes your communication twice as fast
Yeah, a blunt marketing statement like this needs to be backed up, or the bs-markers are over 9000. During the planning phase we tested with a couple of businesses what happens, when we integrate their most commonly used data into a facebook-like autocomplete. The results were, that the initial time they spend using the prototype was reduced to 52% (notable: They were still sharing the same amount of information). I think the reasons for this was a reduction of back-and-forths, misunderstandings and that they generally kept their conversations shorter.
Maybe we should make a short clip, explaining the research that led to the assertion.
By the way, thank you guys for racing your concerns. This sounds cliché but I rather have somebody tell me what he doesn't get/like about ChatGrape than having somebody dismiss our product without us knowing, how to improve.
(posts can be edited for a short time after posting)
Not sure the niche that people like us like to imagine is actually there and underserved by the big enterprise players.
Leo from ChatGrape here. We're focusing on two areas of innovation, to add a certain level of intelligence to chat based team communication:
1. Deep Service Integrations: Our integrations of tools and services like Gmail, GitHub etc function on a much more integrated level than what has previously been achieved. For instance, on ChatGrape, all your issues (GitHub) and files (Google Drive / DropBox) are available within the chat, thanks to a smart auto complete that attaches or references all your documents - right as you type.
2. Speech Act Detection (Natural Language Processing): This is all about the triggering of workflows based on normal, "day to day" communications. For example, if I were to write, "Hey Tobi, let's meet up tomorrow at 2pm to discuss the front end issue!" three things will happen: First, you'll be notified, second a calendar event will be added to your Google Calendar and third, the topic or issue will be automatically referenced or attached.
Natural language processing within ChatGrape goes much further, anyhow, and is a topic where our engineering team has gained many years of experience with previous projects.
We're using to make communication simpler and more efficient, whilst not disrupting your normal flow of conversation. (Another example of this is to automatically detect and mark whether / or questions, and mark them as such.)
ChatGrape went live in an Early Access Phase (Pre-Beta) phase about six weeks ago and not nearly everything of what'll ultimately make ChatGrape the first smart communication solution for teams is fully operational or even deployed yet.
However, what I wrote above will give you guys a better idea of it is that sets ChatGrape apart from all existing solutions like Slack or Hipchat.
I'm looking forward to your feedback and questions and I'm always available via lf@ubergrape.com! And we'd of course be happy about you guys joining our Early Access Phase to provide further feedback.
I think that the vast majority of your target market is already using Slack or Hipchat or something like that, and switching chat systems is a big deal. It's a pain in the ass and not something you want to do.
So, is the NLP feature good enough to make people switch? I would argue that it's not. But, if your NLP actually does add a lot of value, then it's probably good enough that it could be an addon feature to Slack or any of the other chat services.
So, here's my idea: make a hosted NLP bot that integrates into whatever chat system you're using (super easy with Hubot). Then, I can continue to use Slack/IRC/Jabber/HipChat, but I could also buy your chat bot to augment with NLP stuff.
It opens up your market by not requiring people to switch chat apps, and lets you focus on what it seems like you want to focus on the most anyways- NLP.
I like the idea of using various forms of markdown to call out to other data sources, and run in what seems to be sentiment analysis and other work across a chat client - it's a really good idea for enterprises over a certain size - but any enterprise over a certain size will laugh at the idea of having it's informal but utterly core competancies stuck on a server in SV next to its competitors chat records.
This sounds like it's crying out to be an internally managed service with a bot in every room. That way the benefits accrue and the data stays in house.
But love the feature concepts - chat is part of what I am calling the "Open Methodology" and a big win for most companies that embrace it
This scrolling feels god-awful on a high speed trackpad AND a free-scroll mousewheel. Awful. Congratulations on giving a stupidly bad first impression, guys.
Stefan (ChatGrape)
"Deep services integration", where is the API? Hipchat is able to integrate with 50+ services because they have an API which let's other people do the actual work, how can you compete with that level of integration without one?
Thanks for the feedback.
I tried to answer the first one in the longer paragraph -> https://news.ycombinator.com/item?id=8312972
Regarding the API:
We actually have an activity API (similar to Hipchat), through which any service can connect and push activities into our client.
The "index API" will take longer to release, as it is a lot more complex and less explored.
You see, Hipchat/Slack/etc. only allow you to see the latest activities of your service. As "Deep Service Integration" means that you can access the Service's data as you type, integrating a service into ChatGrape is a lot more challenging.
With Google Drive, for example, we have to index the files, and update said index on actions like file renames, deletions, movements, and many more - additionally to displaying activities.
The good thing is, we are getting a lot better at it and the more we grow, the more services will hopefully try to exploit our richer interface.
I see it like this: The 50+ integrations of Hipchat don't matter to 90% of the people, if we integrate the 10 most commonly used services 10 times better.
Best, F
This sounds odd to me (not a native speaker). Waste time where it doesn't matter, instead?
Most importantly, with ChatGrape we're going beyond of simply providing a chat based communication solution. On ChatGpape, we're offering a smart engine that automatically triggers workflows based on your communication, such as, let's meet at 2pm tomorrow - automatically adds a calendar event.
There's more than that, of course, but the essence is that we're running a quite extensive engine in the background to make your team's communication easier and more efficient, and that takes up actual processing power.
Finally, considering that our aim to to save you time that you can use better on building your own baby, instead of wasting time searching for documents you ant to share and issues you want to reference - the average startup using ChatGrape has access to all the features for around 35 bugs per month, which is really a reasonable price, don't you think?
How does that pan out when 2pm is not good for the other person?
"Hey Greg, let's meet at 2pm tomorrow."
"Sure, great. Wait, I have that code review starting 1:45, so 2pm is not a good time. Shall we meet at, say, 11am instead?"
"No, 11am is not good for me. Let's meet around noon tomorrow?"
"Got to pick up the kid at noon but I'll be back at work around 12:30pm. Can we meet over lunch at 12:30pm? I am free till the code review starts."
"OK, let's meet at 12:45 then."
"Cool!"
Does this add five calendar events to the calendars of both the people in the conversation?
I'm trying to figure out if I can get Slack into the workplace but if ChatGrape has something that's very agency-specific, I'll be more likely to recommend it instead.
As far as differentiation, there are some services with unique features and some that are offering good products for free, no string attached (restrictions on message history for example). I would check out Kato (kato.im) and if you are more interested in a "Twilio for chat" try Layer.
What is difference here? Why would we switch?
Cheers,
Leo (ChatGrape)
Frontend: component (https://github.com/componentjs/component) with a lot of custom components, no frameworks.
Using https://codeship.io/ for continuos integration/delivery
Stefan (ChatGrape)