Dashboards are used pretty heavily by development, operations and product teams nowadays, but earlier this year we in Customer Success got to thinking that we could really benefit from them too. We’re very focused on customer feedback and key performance indicators – they’re how we keep track of how well we’re doing. Also, our team is growing very quickly, so we needed a better way of communicating current issues and alerts across the team. So, what better than to get this data front-and-centre on a big TV that the whole team can see?
If you’re interested in the technical details of how we pulled it off, and how well it’s been working for us, read on!
Dashing to the rescue
The folks on the dev side of our office introduced us to Dashing, an open source app built at Shopify, which they have already been successfully using for a while. Dashing is an awesome (and “exceptionally handsome”) Sinatra-based dashboard framework for Ruby. It’s great at taking a lot of the hard work away from creating awesome-looking dashboards, which is exactly what we needed!
Each dashboard in the app typically consists of a ‘job’ and a corresponding ‘board’. The job is a Ruby script that does the heavy lifting – periodically grabbing the data from API endpoints, processing it and pushing it to the board using Server-Sent Events.
The board itself is a view that receives the data and displays it it in colourful widgets. Dashing comes with a wide variety of pre-made widgets (numbers, graphs, lists, text, etc), and in the end we only needed to customize these a little.
And, when everything is ready, it’s really easy to deploy the Dashing app to Heroku, for free. This meant we were able to get the whole thing up and running, beginning to end, without needing to take any time away from our busy developers.
Number crunching
One the most important things we wanted to see in our dashboard was the amount of customers that are at each stage of the customer lifecycle. This would let us know how well we are onboarding and retaining customers through their time with Unbounce.
We already use Intercom to segment and analyze our customer base, so this was as simple as using the ‘intercom’ gem to pull the amount of users that are in each segment.
The rest of the dashboard mostly related to our net promoter score (NPS) survey responses. First, we wanted to see the average NPS scores for both our support and the service as a whole, at each stage of the customer lifecycle, and for the current month and over time. We also wanted to see the most recent comments left by customers that filled out the survey.
At first I thought about setting up a database that we could feed our survey response data into, and then query to get data for the dashboard. However, since this would require a fair bit of setup and maintenance, in true Unbounce style we decided to go with the minimum viable product approach. We had already been feeding survey data from SurveyGizmo into various Google Drive spreadsheets so the whole team could view the results, so we decided to just grab the data straight from there. We ended up using the ‘google_drive’ gem, which worked really well for this.
This way, we could leave Google Drive to do the hard work of aggregating the data and running calculations (for example, to give us stats for each month and for each Customer Success Coach), and simply pull the results of those calculations into our dashboard, as well as the raw data of the most recent comments.
We also ended up using Google Drive as the backend for an ‘alerts’ dashboard – the place where we could keep the whole team updated on current events, bugs and outages. We wanted one centralized place where anyone on the team could easily add or remove alerts, and while we could have developed some kind of web interface, it quickly became apparent that it would be way easier to create a simple Google Drive spreadsheet that anyone on the team can edit, and simply pull the alerts from there.
TV time
With the coding work done, we just needed a way of displaying the boards on a big TV screen. At first we considered buying a Mac Mini, but at $550, they’re a little steep for what we needed. The beauty of running a dashboard this way is that almost all of the hard work is done in the cloud – on Heroku, Google Drive and Intercom – so all we really needed was a web browser and a little memory.
What better use for a Raspberry Pi, then? It’s a credit card-sized computer that costs around $40, not $550 – and, even better, it doesn’t require too much power, so we were able to power it from a spare USB port on the back of the TV. This means when we turn the TV off at the end of the day, the Pi turns off too!
I found a great article and script from Geckoboard which gave us a good start on getting the dashboard running on the Pi. Although they suggest using the Chromium web browser, I tested a few alternatives and found Raspbian’s built-in Midori browser to be slightly quicker.
So, here are a few of the steps I took to set it all up:
Imaged an SD card with Raspbian, a Debian-based Linux distribution that’s designed specifically for the Pi.
Booted up the Pi and overclocked it a little (sudo raspi-config) to squeeze out a bit more power. Here’s a guide to that process.
Wrote a bash script to run when the desktop environment starts. It hides the mouse cursor and opens Midori to the dashboard’s URL in a fullscreen ‘kiosk’ mode.
Wrote another script that allows me to SSH in to the Pi and restart the browser without needing to reboot completely.
You can see the final scripts that I ended up using here.
Getting on our bikes
Now that this was up and running, we had one last problem: we had three dashboards but only one TV.
At first, we used the ‘sinatra_cyclist’ gem. This let us automatically cycle through the dashboards at a set interval – after some debate, we settled on 20 seconds. And, it was nice and easy to set up, because it’s designed to work with Dashing right out of the box.
While this was a good start, it didn’t work amazingly well, because every 20 seconds the next board had to be loaded from scratch. This led to a clumsy transition, because the Raspberry Pi – with its limited resources – takes a few seconds to load and render the widgets, one-by-one.
So, after a few months, I decided to work on a solution that better suited our needs. I ended up with what I call ‘Dashing Cyclist’. Instead of loading the next dashboard each time, it loads all of them at once, and uses JavaScript to visually cycle through them. While this undoubtedly requires more memory and means the initial load is much slower, it does lead to way smoother, instantaneous transitions between each board, and the result is a lot easier on the eyes! It’s available on Github – feedback and pull requests are more than welcome!
The results
We love our dashboard! I think we’ve successfully proven that dashboards aren’t just for developers and product teams. It places our customer feedback front-and-centre, which means we can easily keep track of our NPS scores over time, and that we can enjoy and learn from written feedback as soon as it comes in. It means that we’re always aware of how our customer base is growing and how well we are supporting them through the various stages of the lifecycle. It means the support team can clearly see how well they are individually doing over time, and compete against their past selves! And, it means the whole team is informed about up-to-the-minute events, as they happen.
The dashboard is very much a work-in-progress, too. Everyone on the team has their own opinions about what the want to see on the big screen, and we’re working hard to make a dashboard that works for everyone.
Here’s what Justin had to say: “Overall, it’s just great to have some visibility into what we’re doing as a team. It’s super rad to overhear other people in the office talking about our scores!”
– Mark Wainwright
Technical Support Specialist