Ben Porterfield
co-founder and VP of Engineering

At Looker, we tried out Slack about a year ago and knew almost immediately that it was for us. Our email was already (and still is) overflowing with giphy images and emoji reactions. Slack felt like the perfect platform for our internal gif-and-emoji-reaction culture. I suppose that it also worked reasonably well for chat.


Nowadays we’re heavy users: departmental discussion channels, project-based channels, channels for one-off topics, and a whole lot of gifs. We’re starting to resemble a hip modern family 😍. We love it! (Here’s a tip for you Slack users: if you don’t know about Esc and Shift-Esc in Slack, LOOK IT UP)

We share a ton of data from our own internal Looker via Slack. Every table, chart or dashboard in Looker has a unique URL, so a lot of URLs get pasted into Slack conversations to support decisions or arguments. Hooray for data-driven conversations!

Frank (our CEO) rightfully kept bugging me with “why doesn’t the data appear in the conversation” questions. He was looking for the link-expanding experience where the content of a URL appears in-line inside the chat window - wouldn’t it be faster if you could just see and chat about the data together?

Our first pass at an integration was exactly that - injecting the table or chart into the chat window whenever a Looker link was shared:

Looker URL in Slack

This was neat, although sometimes surprising to folks who didn’t expect it. It turns out that we didn’t want every channel to automatically expand the links, and this feature still required a trip outside of Slack to our Looker mid-conversation to find the link to share. We thought we could do better.

What’s clearly more desirable is the ability to ask for data on the fly without leaving Slack. We were sure that we wanted to create specific commands to request data from Looker, but how would we make them useful? The commands would be different for every company; at Looker, we might want to ask the Lookerbot for the name of an account manager who is the point person for a specific customer. Another company might want to ask about the latest shipment of inventory in the warehouse, or how many food deliveries happened in the last 2 weeks.

We wanted the ability to dynamically define these commands for the bot, and we didn’t want the creation of those commands to be restricted to the developers or analysts. Requiring developer or analyst intervention means that when someone has an idea for a new Lookerbot command, they have to wait for the developer to create it. This sounds like a data breadline to me - not ideal.

Wil (an engineer at Looker named after Wil Wheaton 🚀) had a real 🌋of insight: Looker has an API to list the contents of a “space”, which is basically a folder of dashboards and saved reports. We could make a space that the Lookerbot could be configured to read via the API, and could then turn each report in that space into a command in Slack using the title of the report.

Even more radical, since most of the reports accepted values to filter the dashboard, the commands themselves could be dynamic! This method would give us commands, editable by business users, that were dynamic and useful. Win-win-win.

The first folks Wil showed the Lookerbot to was our own Account Management team. Within a few hours, the majority of their Looker usage - looking up client health, contact information, and contract terms - had moved to Slack. They were inventing commands like “/looker customers in city {city name}” to get a list of customers in a given city, or “/looker contact {customer name}” to get the email and phone number our contact at a customer that they needed to get in touch with.

Slack and Looker

This was completely unexpected! We thought they’d like it, but didn’t think they’d immediately spend time perfecting their commands in it. The most amazing part was that they were iterating on their in-chat workflow and inventing a process for using data in Slack conversations that hadn’t existed a week before.

Custom commands are the hidden power behind the Lookerbot, because they put access to data in the hands of anyone that can create content in Looker. Our account managers were working smarter and faster (pretty much inconceivable since they were already exceptional to begin with). They had quick access to data inside of their conversations and this contributes to building a data-driven culture and decision-making - it’s impossible to ignore someone using data to back up an idea, and there’s a rapid shift to replicating this strategy once it has been experienced.

We saw this shift ourselves: since they were using the Lookerbot in various channels that weren’t specific to Account Management, other folks started to pick up on the feature - soon we had Lookerbot commands for just about every department at Looker, without ever needing to contact a data analyst or engineer for help :muscle:.

Looker and Slack are on similar missions - to change the way people work.

Looker is changing how people make decisions by making it easy for anyone in the company to access reliable data anywhere they need it. Slack is bringing better, more collaborative, communication to make it easy to connect and move business forward faster.

Data driven cultures result when everyone can easily access and bring data into conversations and make meaningful decisions underscored by a deeper and more complete view of what is going on.

Seems like a good fit right? 😎

The Lookerbot is built entirely on the Looker API and is available here - just grab it and go.

Subscribe for the Latest Posts

Next Previous