Summary
Arvind Ramesh is the manager of the data team at Envoy. In this post, we’re sharing how Arvind’s team has built a data platform at Envoy, with a deep dive into a data product for the Customer Success Team. Arvind believes that the most important skill in data is storytelling and that data teams should operate more like software engineering teams. You can find Arvind on LinkedIn
For more detail, you can also watch the full video of our conversation.
Data at Envoy: Background & Business Context
Envoy helps companies manage their office visitors and deliveries. Chances are you’ve already used Envoy somewhere in a lobby or a reception desk, where an iPad kiosk runs the Envoy app. The app checks you in, prints your name tag and sends your host a message that you’ve arrived. Guests can also use the “Envoy Passport” app for automatic check-in, collecting different “stamps” for each office visit, similar to visa stamps at customs when entering a country. Hosts can manage visitors and other things like mail and packages via a mobile app.
The apps generate a new, growing amount of data on a per-minute basis. Envoy has welcomed over 60M visitors, adding 130,000 new visitors every day, in over 13,000 locations around the globe. Envoy’s business model consists of a subscription where pricing scales with the number of locations and deliveries. Providing analysis and reporting for decision making across that location and visitor footprint is of course valuable.
But basic reporting is not a data product. “The way I look at it, a data product, it’s not really delivering an insight per se, but it’s delivering ‘a thing’ that can be used by other people within or outside of the company to improve their workflow’, says Arvind.
At Envoy, data products are about enabling people to do more with the data Envoy generates. “The advantages of data products is that they enable other people to more easily access data and use it in their workflow without us having to go back and forth for every piece of insight”, says Arvind.
Part of Envoy’s secret to success is using a data product to drive account penetration and adoption of the Envoy app.
Who is the end-user of this data product?
The Customer Success team uses Gainsight, a suite of SaaS products for monitoring and managing product adoption. “Gainsight is basically a UI that allows you to better manage your customer base, see how people are using your product, where there are problems, where you might need to focus your attention. But, like most tools, it is only valuable if it has a stream of comprehensive, reliable, and accurate customer data underpinning it.”
Gainsight offers a full customer data platform, but in Envoy’s case the Gainsight app is a “skinny” UI, which sits on top of the Envoy data platform. In this specific case, it’s a table called “Gainsight company facts”. A daily batch process combines data from many different sources into the final table.
“The way I think of it Gainsight, it’s the UI that sits on top of our data platform because it would not be the best use of our time or anyone’s time to build a UI for that kind of thing. The way we think of data products – it’s a backend data service or data infrastructure. The actual last mile is a web dashboard or something similar. Usually we’ll use a tool to accomplish that.”
What Business Problem Does this Data Product Solve?
Data delivered in Gainsight helps the Customer Success team prioritize the accounts where product adoption is below par, and locations are at risk of churning.
Compared to the raw source data that’s scattered across various sources and places, the new “Gainsight company facts” table has reliable, useful information in a single place, such as:
- “how much is this company paying us?”
- “when where they last active with us?”
- “what features are they using?”
- “which ones are they not using?”
“We have a few customer success managers and each of them will have several hundred accounts” says Arvind. “They can have a conversation with the customer, ‘ok, you have 50 offices, but look, these five are actually having some issues and maybe you should focus on these’.” Arvind’s team helps make those conversations more effective with product usage data.
What Are the Data Sources & Tech Stack?
The data for the “Gainsight company facts” table is the result of a daily batch process. The process cleans, transforms and combines raw data from different sources within the Envoy data warehouse.
The image below shows a summary of the graph, or “DAG” involved in building the model. For every company, for every day, the output table contains a variety of key data points.
To run the batch process, Arvind’s team has built a platform that consists of five key components.
-
Data Sources: Envoy has between 20-25 data sources, across internal and 3rd party systems. For Gainsight, the relevant sources include for example Envoy’s production databases, Segment event data, customer support tool (e.g. ticket volume), the billing system, email systems and Salesforce.
-
ETL tools: To get raw data from the source into the warehouse, Envoy uses off-the-shelf tools wherever an integration with a data source is available, including Amazon Glue, Fivetran and Stitch Data. “For loading data, our general philosophy is that it’s a solved problem and we use a tool. For custom ingestion, we builds a script using Singer”, an open-source ETL framework sponsored by Stitch Data, with orchestration via Airflow. Data loads happen up to every 30 minutes.
-
Data Warehouse: Envoy loads raw data into Amazon Redshift, with dense compute nodes (dc2.8xlarge).
-
Data Modeling: Once data has been loaded into Redshift, transformation happens in SQL with dbt, an open source analytics engineering framework, to create the final output tables, e.g. “Gainsight company facts”.
-
Data serving / “Last mile”: In the specific case of Gainsight, the final table is unloaded from the warehouse into a designated S3 bucket from where Gainsight picks it up. Other tools may require a different format. The key part is that all of the logic is encapsulated in a model, and the final table(s) can have different destinations, e.g. an S3 bucket, a query within Redshift, a data API, or a data microservice.
The model for Gaingisht takes about 40 minutes to run, including completing all upstream dependencies for the freshest possible data.
For other data products, the SLA can be a bit more real-time, and models run every three hours or even shorter. But “typically it’s pretty rare for people to truly need data real-time or even close to real time, unless it’s something operational or you’re looking at server metrics.”
Best practices and lessons learned
Next to customer success, the platform supports other data products, and building the underlying models requires domain knowledge.
“That’s typically where we do a lot of work on our end. You really have to understand how our business works, how our activation metrics are defined, or how our products interact with each other”, says Arvind. Usually one person is an expert for a specific domain, but with peer review, documentation and a QA rotation, domain knowledge starts to make its way across the team.
“Our team is eight people and that’s split across data engineering, product analytics and go-to-market analytics. We’re about 170 people right now total at Envoy, which translates to about 5% of the company working in data-focused roles. “If we build effective data products and continue to iterate on operational efficiencies, our team should not have to scale linearly with the company.”
Building the platform has been an iterative process. “It’s probably a bit cliché, but I think data teams should work more like software engineering teams”.
First was testing. “After building out the first set of several dozen models, we quickly realized that ensuring everything stayed accurate was a challenge. People were finding issues in the data before we were, which was embarrassing for us since we felt accountable for the accuracy of anything we put out. The upstream data was at times incorrect, and could change in ways we hadn’t anticipated. So we implemented tests, which are basically data sanity checks running on a schedule that checked the intermediate and final transformations in our pipeline. But then, when some of these tests failed, it’s not evident who on the team was responsible. They went unfixed for a long time, as each member of the team thought someone else would fix the issue”.
So next up was QA rotation. “Now, every week, there’s someone else who’s responsible for fixing any data test issues that pop up, and the ‘oncall’ schedule is managed through PagerDuty”. As the company and the data team keeps growing, the person who is responsible for fixing a failed test may not understand the full logic that’s going on.
That meant better documentation on how things are built and how to debug tests. “And again, I keep drawing this parallel, but if you look at any software engineering team, and open up our knowledge base, you will likely see a postmortem for every outage and issue that happens, and runbooks to fix them.”
Arvind’s team has started to use the data platform for advanced data products, like churn prediction and machine learning. Envoy is trying Amazon SageMaker for that.
Another project is integrating the data platform with the customer-facing analytics. “Obviously, when people log into Envoy, there are already analytics. How many visitors are coming to their office, how many packages they’re scanning. That’s done through a white-labeled solution with a BI vendor”, says Arvind.
“But eventually the data team is going to build an internal microservice where the Envoy app will just request what it wants and then we will return a bunch of things that we think are valuable”.