As those of you who know me personally can attest, i’m never particularly enamoured with the phrase – “Thats just what we’ve always used”, or “Thats just how its been since i started”. Im a firm advocate of the Winston Churchill quote “To improve is to change; to be perfect is to change often.” and yet I feel that a lot of companies fail to do this.
A lot of us in IT like to reminisce about “Oh wow, 2.5″ floppy drives – I bet you dont even know why there isnt a B drive in Windows do you?” (Or worse still with the older generation – “Oh VAX was the best..”), instead of looking at the drawbacks which led to the eventual demise of these technologies. I feel the same can be said for email; its so engrained in corporate culture that no one has actually thought to product analyze email itself – in terms of:
1. What problems does it solve?
2. Is it fit for purpose and easy to use?
3. Is it advanced enough to allow for further growth and evolution?
In 1971 when ARPANET first devised email, I imagine the above were true – but it was also true that it would be 4 years until Microsoft would be founded, and another year until the breakthrough Intel 8008 microprocessor would be released. Nowadays, email tends to be the cause of more problems that it is worth, especially when used inter-company.
Dont get me wrong, I dont think email is all bad – for starters, how else would Sales teams communicate with customers? How else would electronic invoices be sent? How about emails that need to be tracked for auditing purposes (i.e. formal notices from HR, legal, and so forth)?
I think email has the same purpose as the one a postal system holds; content delivery rather than collaboration and speed. However, in the last 10-15 years email has been used more and more as a collaborative tool between teams and departments, leading to infuriatingly long email threads, reply-to-all’s, and a lack of dynamism that can really hurt companies in the fast moving society in which we currently inhabit.
Email is also prone to abuse – we have:
1. Spammers / Scammers
2. Automated junk from websites and services
3. Junk you might have once thought of as a useful idea (i.e. “Oh its great that Salesforce emails me everytime a lead is created”).
Along with a million other ‘Junk rule’ creating annoyances.
So, what is the answer?
Recently, I’ve been working more and more in the world of ‘integrations’, taking data and events from one tool and doing something in another – and this has exposed me to a world of possibilities in terms of – “Why cant this idea be taken and applied on a company wide scale?”.
What if instead of having hundreds of folders containing automated emails – and then having to forward these emails to colleagues, then skype them “Hi, about that email..” – you could both see the ‘event occur’, and then discuss it live, along with the rest of your team?
In my company alone, we use at least 10-15 platforms across departments, ranging from ServiceCloud for customer success (nee: technical support), Salesforce for CRM and Sales, Jenkins for builds, Git for storing magic, JIRA Agile for SCRUM/Agile, ProdPad for Product management, and so forth. All of these tools generate events and it would be awesome if we could quickly access and collaborate on these; yet currently we (like many others) are reticent to set up email alerts as they will inevitably annoy us and be tossed into junk via a rule.
A potential answer? A chatroom-like tool that allows feeds directly from the aforementioned tools, but at the same time allows for the dynamic creation of rooms/group chats, sharing of files (Docs, images, etc) and more importantly – dynamic discussion and resolutions. Namely, Slack or Atlassian Hipchat.
Hipchat
Hipchat is a free (for normal use) tool from Atlassian, the makers of JIRA, JIRA Agile, Confluence, BitBucket and more. It allows tools such as their aforementioned products to send data and messages into various ‘rooms’, such as ‘Engineering’, ‘Support’ and more – meaning that if a new customer incident is raised in JIRA, it will appear in the Support room within seconds, allowing support engineers to quickly discuss the incident and assign appropriately.
There are a number of Hipchat integrations available here, ranging from GitHub and Drupal through to email and even Opsview (i.e. ‘customers edge router has gone down, send a message into the Networking room to tell them).
Slack
Slack is like Hipchats better looking, cooler younger brother. Its much more user friendly, the UI design is excellent and I love how easy it is to setup. The main differences I found with Hipchat and Slack are:
- Hipchat seems more corporate; you have an IRC style interface for a start – with a list of users on the right that you can double click on to either IM or video chat (are people STILL trying to flog that as an idea? Let it die!).
- Slack is easier to use and is a hell of a lot prettier from a UX perspective, which ALWAYS helps adoption.
Integrations
The issue I found with trying to setup Slack and Hipchat as my email-killer, is that whilst they offer integrations, they dont offer an all-encompassing range that fits my needs perfectly, and as im not a developer I’d have no idea where to start in terms of writing my own integrations.
For example, with Hipchat the integration with JIRA Agile is excellent, you can be notified for all sorts of things – which is what you’d expect from 2 tools from the same vendor, however they offered no integration with Salesforce or ServiceCloud. Likewise, Hipchat had some neat integrations via webhooks, but also fell down on Salesforce integration, and their JIRA integration is pretty poor.
In order to get messages from these vendors into the ‘chat tools’ i just mentioned, you have to use another product that has popped up in the market in recent years, an ‘event broker’.
Event brokers
An event broker is essentially a man in the middle, who takes data from one tool, formats it, and sends it to the other tool – for a nominal fee (or free, depending on your tool de jour).
The benefit of using event brokers is that as long as they can talk to your chosen client (Hipchat, Slack, etc) then its generally much easier to setup integrations as thats their bread and butter. A few examples of event brokers are:
- Zapier
- IFTTT (If This Then That)
- Cloudwork
- Elastic.io
- We Wired Web
Some of these tools are free-free, such as IFTTT, and some are free to a point, such as Zapier, WWW and more. The pricing tends to hinge around:
- Number of integrations
- Frequency with which integrations can be delivered
- Total messages that can be sent per month
- Users
In my testing, I have so far looked at IFTTT and Zapier.
IFTTT
Verdict? Its OK – probably more use for home users and script kiddies than to a business, judging from the list of integrations:
It doesnt have Salesforce support, JIRA support, or other items like Jenkins etc however it does have GitHub support.
Zapier
Verdict? Pretty good! It is incredibly simple to configure and use, and linking your accounts (i.e. the Salesforce account you want to get information via) is VERY simple to do. The configuration of what you want to send is also very simple, as it sucks the fields in from Salesforce, Twitter, or any other tool you want – for example, I want to send a message into my marketing room whenever my company was mentioned on Twitter, so they can discuss if they need to respond, etc.
To do this, I set up a new ‘Zap’ as below:
Trust me, it IS as easy as that. And now, whenever anyone tweets with the words ‘Opsview’, it will appear in our Marketing teams Slack/Hipchat room. Observe:
We can now discuss the tweet, respond if its a query, pass it onto Sales if its an enquiry, and so forth! All done without a single email. Ah the bliss.
What next?
The end goal is to have a fully automated solution, that takes in inputs from all of our chosen tools, uses an event broker (if required – some tools can output directly into Slack/Hipchat using Webhooks), and puts them into the correct room, in the correct format – allowing for quick diagnosis, recognition – and most importantly, COLLABORATION.
Heres a little screenshot of what ive set up so far:
Here, we are sending a message into the #sales room in Slack when a new opportunity is created (via the website or an account manager). We are sending an alert into the marketing room when we are tweeted about, and when a customer raises a ticket in ServiceCloud – the support team gets an alert. The plan is to roll this out to our other functions, then start the most painful part – driving adoption!
Potential barriers to adoption
So – this things bloody marvellous, why wouldnt anyone want to use it? Well there are a few areas:
1. It doesnt have a calendar functionality, meaning people will still be using Outlook to send calendar invites, and view other users diaries.
2. People are familiar with Outlook – meaning that when driving adoption, highlighting the advantages of this disruptive move (Crossing the Chasm, Geoffrey Moore) is going to be key to its adoption throughout.
3. People use Outlook for task management – Simple, use something designed for that purpose like Wunderlist, my personal lord and saviour of time management. Again however, there is likely to be some pushback on this – given people are still using IE, Id be amazed if they jumped on something like Wunderlist without reticence.
Conclusion
To conlude, email is good for external communications – but in my opinion, stay away from outlook when thinking of internal communications – it might have been the way to do it 20 years ago, but with the rise of event brokers, tools like hipchat/Slack, and an onus from software vendors on creating an easy to use API to allow for automation, the days of “email for everything!” is nigh – collaborative tools will drive customer success, and eventually the success of your business as a whole.
I see event brokers becoming more and more prominent amongst a user base who wants integration without the development headache – forcing vendors to create ‘recipes’ for these platforms such as IFTTT, Zapier, and co. Overall – software will become better at talking to other tools, which can only be good for customers.
