Launch HN: Scribe 2.0 (YC W17) – Configurable, Actionable Alerts on Slack
5 comments
Hey, congrats!
This seems really cool. As an engineering manager, I can't see how I'd make use of this in my day-to-day, but I could definitely see the sales team using it.
One of my biggest questions is: why Slack? It seems like the majority of the incoming streams would come from email. And it seems like you're targeting integration with SalesForce -- at least that's what I get from the home page.
Other than that -- not to nitpick, but there's a grammar error in your first graphic: https://www.tryscribe.com/static/img/email.png . It says "You've have an email".
This seems really cool. As an engineering manager, I can't see how I'd make use of this in my day-to-day, but I could definitely see the sales team using it.
One of my biggest questions is: why Slack? It seems like the majority of the incoming streams would come from email. And it seems like you're targeting integration with SalesForce -- at least that's what I get from the home page.
Other than that -- not to nitpick, but there's a grammar error in your first graphic: https://www.tryscribe.com/static/img/email.png . It says "You've have an email".
Haha, Thanks for pointing it out. Will change it soon. One of the biggest reasons we chose slack as the notification consumption platform is to enable collaboration(and therefore more visibility across teams) as we expand to more usecases outside of sales. We therefore built a robust email <> Slack integration as well.
Also, one of our main USP is the ability to take action on any notification. Slack provides a strong api layer to pull this off, while its extremely tough to do the same as a gmail app. Chrome extension is still a viable option, but for now, we chose to go ahead with Slack due to the collaboration element.
Regarding the engineering manager usecase, although we don't have deep relevant integrations yet, we are considering adding support for Jira, Trello and Sheets as well, but would love to know if any of that will be as helpful in your day to day work. We are not venturing into tech alerts yet, as there are good comprehensive solutions already in place but would love to know of any gaps that might exist where a configurable action layer would be helpful.
Also, one of our main USP is the ability to take action on any notification. Slack provides a strong api layer to pull this off, while its extremely tough to do the same as a gmail app. Chrome extension is still a viable option, but for now, we chose to go ahead with Slack due to the collaboration element.
Regarding the engineering manager usecase, although we don't have deep relevant integrations yet, we are considering adding support for Jira, Trello and Sheets as well, but would love to know if any of that will be as helpful in your day to day work. We are not venturing into tech alerts yet, as there are good comprehensive solutions already in place but would love to know of any gaps that might exist where a configurable action layer would be helpful.
Cool, yeah, I figured it would be a lot trickier with Gmail, and it seems like you guys are taking advantage of some Slack UI features.
Jira is the only tool I use that you mentioned, and as far as that goes, I'm not really sure what I'd take action on. I get a bunch of notifications about ticket updates, but I mostly ignore those. The one thing that would be pretty awesome -- which I think Atlassian already does, we just don't have it configured at my company -- is to be able to respond to comments from Slack.
Jira is the only tool I use that you mentioned, and as far as that goes, I'm not really sure what I'd take action on. I get a bunch of notifications about ticket updates, but I mostly ignore those. The one thing that would be pretty awesome -- which I think Atlassian already does, we just don't have it configured at my company -- is to be able to respond to comments from Slack.
yup. makes sense. Jira does provide those. The main element missing in native slack apps is the ability to send data across different integrations. So, some cases where a cross channel support that we provide might be handy is if you want to create jira ticket from email, update sheets from jira notification, reassign tickets and update calendar based on email etc, but not sure how often you will need something like this. but if you do, let us know and I can reach out to you directly.
Congrats on the launch!
Why did you decide to tackle event-driven workflows with humans in the loop over human-initiated workflows, e.g. making a new staging env? Did customer research suggest that event-drive workflows were more valuable?
Seems like there's still lots of room for companies to adopt chatops solutions, with Slack as a central access point. Or not, of course, as we saw with the overhyping of the chatbot.
Why did you decide to tackle event-driven workflows with humans in the loop over human-initiated workflows, e.g. making a new staging env? Did customer research suggest that event-drive workflows were more valuable?
Seems like there's still lots of room for companies to adopt chatops solutions, with Slack as a central access point. Or not, of course, as we saw with the overhyping of the chatbot.
Thats a very good question. There were 2 main reasons for that. There are a lot of chatbot solutions to enable human initiated workflows while there were hardly any solution which enabled human in between an event driven workflow. But more importantly, since we came from a sales focused market and faced the problem of supporting human element within an event driven workflow ourselves, it was easier for us to get the relevant customer feedback.
Also, chatops right now is mostly human initiated and is focused on tech. We wanted to tackle enterprise integration market where the need seemed more immediate. A lot of the people we talked to hated logging into their CRMs and updating them at regular intervals can be a very tedious task. Hence we decided to prioritize event driven workflows with human in between, while keeping the architecture open to support human initiated workflows triggered from slack as well.
Also, chatops right now is mostly human initiated and is focused on tech. We wanted to tackle enterprise integration market where the need seemed more immediate. A lot of the people we talked to hated logging into their CRMs and updating them at regular intervals can be a very tedious task. Hence we decided to prioritize event driven workflows with human in between, while keeping the architecture open to support human initiated workflows triggered from slack as well.
My $0.02c - I opened your website and didn't immediately understand your product. It wasn't until I read the guts of your HN post that I figured it out.
Maybe invest a couple of days into researching/testing different (above the fold) taglines with random people off the street to see how quickly they guess what your product does?
Maybe invest a couple of days into researching/testing different (above the fold) taglines with random people off the street to see how quickly they guess what your product does?
yup. makes sense. Thanks for the feedback (y)
If you don't me asking, and I don't mean to sound rude, but - what took so long to launch? 2017 YC to 2019 launch is a really really long time for what seems like a basic tool. Everybody I know has cobbled something together like this using Zapier/IFTT and other integrations or custom microservices, it just seems like you're a bit late to the starting line.
Hi sure. Fair question indeed. We were a sales call scheduling service till september 2018 and had built a strong email categorization and reply layer on top of collaborative inbox to manage multiple client inboxes, schedule calls and update CRMs. By late last year we decided to push to a pure SAAS play and eliminate the human-in-the-loop segment of the company. You can think of this as a soft product pivot to achieve scalability and reduce operational overhead.
That said, since we allow AI enhancements on the event data (email categorization to be precise for now) on top of the zapier model and also allow the human decision making element in between, we could not just plug and play any IFTTT architecture, which definitely meant some more engineering overhead.
That said, since we allow AI enhancements on the event data (email categorization to be precise for now) on top of the zapier model and also allow the human decision making element in between, we could not just plug and play any IFTTT architecture, which definitely meant some more engineering overhead.
How would you compare your product to other similar solutions like Zapier?
hey, thats a very good question and one that we get very often.
Zapier is a complete automation suite where in an event will automatically trigger a bunch of actions without the ability to modify the event data or decide the action based on the event.
We enable all these usecases where a user will have to see the event and then chose which set of actions to trigger. the user can also send a modified version of the event data to the actions, while in Zapier, the event data consumed by the action layer cannot be updated in real time.
Zapier is a complete automation suite where in an event will automatically trigger a bunch of actions without the ability to modify the event data or decide the action based on the event.
We enable all these usecases where a user will have to see the event and then chose which set of actions to trigger. the user can also send a modified version of the event data to the actions, while in Zapier, the event data consumed by the action layer cannot be updated in real time.
Well Zapier has filter and formatting so you can modify data and also filter them https://zapier.com/apps/formatter/integrations/
filter and formatter are still set at the time of workflow definitions and are not real time. When I say real time, I mean that the user in our case can see the exact event (like say the content of the email, ticket or crm update etc), and then decide to take an action. And when he/she is passing event data to that action, they can update it based on what they see and not what they expect as is the case with other automation platforms. In effect we are more interactive workflows than automated workflows if that helps.
Thank you for the clarification. Seems like Zapier is also moving to your space, with slack interactions (this came to my inbox yesterday) https://zapier.com/blog/updates/1969/zapier-slack-action
We’re Sachin and Rutika, founders of Scribe (https://www.tryscribe.com). Scribe 1.0 provided sales call scheduling service managing client’s sales inboxes, scheduling sales calls and updating their CRM based on email and calendar events. We did this through a human in the loop (software+service) approach. In the process of managing external conversations we built an internal SAAS product which helped us stay on top of all the email and CRM updates. We are opening it up today for others to use as a standalone product calling it Scribe 2.0
It’s an extensively customizable workflow builder which allows you to receive events from your email, calendar, salesforce and Stripe accounts either as Slack DMs or notifications in slack channels of your choice. You can configure any number of API actions on top of these events and based on the event contents decide what actions to take with couple of clicks right from slack. We also have a HTTP/webhook option to support custom events or events from other integrations as we explore expanding the workflow builder for more usecases.
Some of the sample usecases we have been used for include
- Share selective emails in slack and based on the email information, you can reply, send a calendar invite and update CRM with single click buttons without opening any other website.
- You can setup custom reply templates for different email categories, and have them personalized based on the incoming email information
- Create support tickets, add assignees and deadlines, from email in slack
- Trigger ML jobs with updated parameters based on previous job’s success/failure and performance accuracy.
- Trigger code deployments and task pipelines from Slack
In effect, users can configure workflows to send data from any of their SAAS apps to Slack, update it in real time, and send it back to anywhere else. And all this can be done collaboratively allowing for broad visibility and accountability across teams. We also have a cool gif feature that allows one to attach changing gifs based on incoming event data allowing for some nice surprises
Some of the interesting feedback we have received from our customers are
- They go without logging into gmail and salesforce for days
- We are like a mother who nudges them to do the right thing at the right time
Technically, we have built a unified layer for authentication, resource and crud schema inference. We can therefore integrate with any software that is openApi compliant in a matter of few days. Pubsub management however has been quite nasty given the scale, lack of api standardization and the asynchronous nature of the platform. We also have selectively exposed our email AI from the original Scribe 1.0 product, that categorizes sales email into more than 22 different categories allowing users to setup personalized templates and actions based on the intent of the email.
We are looking to HN to get feedback on the product as well as explore new usecases on how we can extend the service to cover more integrations and usecases. Given our history, we have mostly built with sales usecase in mind, but we do believe that now, this can be extended perhaps more effectively to other markets and would love to get HN’s thoughts. Apart from more integrations, we can also provide option to schedule time based notifications as well as ability to define slack commands to pull data/trigger workflows if there is a usecase/market need.