Plain builds real-time customer support insights with Tinybird

Plain helps technical B2B teams control business critical support. Their team is building the support platform that you’d otherwise have to build yourself. Plain is completely configurable – you integrate it with your product and bring customer and product data directly into your support requests.

A new way to think about customer support

When building Plain, the founders recognized that Support and Product are inextricably woven together.

In B2B, and especially technical or developer-focused companies, engineers and product managers have a very close relationship with their customers. It's not transactional support that you might find in B2C, but a symbiotic relationship powered by mutual trust, lots of feedback, and a shared understanding of the customers' pains and goals.

Plain has created a modern support platform specifically for these kinds of companies, giving them powerful workflows to better connect with and support their customers in real time.

The founders and engineers at Plain understood that customer support - the tickets, threads, conversations, and issues - could be a valuable source of data for product and engineering teams. Customer support data can show you your product gaps; the edge cases and corners where customers get stuck and need help.

Plain's customers wanted access to that data so that they could deeply understand the relationship between support and product; to identify where support volume was initiated, the kinds of requests customers were making, or how support and product feedback differed across different customer segments or pricing tiers.

The engineers at Plain were determined to imbue their product with data-driven features that would help Plain's customers spot trends, identify weaknesses, and improve their products.

Looking beyond the "Insights" Page

A common way to add in-product reporting is through some kind of separate page or dashboard where customers can see all their analytics charts and tables in a "single pane of glass."

Plain took a different approach.

Instead of building a single "Insights Page", Plain's designers chose to craft brilliant, data-driven UIs sprinkled throughout the product, with sparklines, tables, tooltips, and components backed by their real-time analytics service.

The challenge with building real-time reporting for support

Plain's user experience is fast. Within its web application, Plain leans heavily on the browser to eliminate loading states and refresh UI components immediately as users navigate through the app.

Any data-driven features that they incorporated would need to fit within this philosophy. They didn't want customers to wait as dashboards loaded; they wanted the data to be immediately available.

At the same time, they also recognized the importance of data freshness. Customer support is a real-time business; ticket states and support conversations happen synchronously, and reporting must be completely up-to-date with the state of reality to be trustworthy.

Compounding the technical challenge was the fact that customer support produces a lot of data. Plain has built a backend architecture that relies heavily on serverless compute and event-driven operations. Every single update to a support thread or customer produces a tremendous amount of data, and the size of that data compounds as event streams are enriched with customer dimensions, tags, metadata, and other useful bits of information that Plain captured for its customers.

Building real-time, user-facing data features at this scale posed a challenging question to Plain's engineers: "How do we do this in a performant way?"

Plain's engineers considered using their existing internal analytics infrastructure, a combination of Segment, Google BigQuery, and Metabase, to power these features. They figured that BigQuery's online analytical processing (OLAP) abilities would be able to support their user-facing needs.

This approach, however, resulted in way too much latency.

Plain wants to focus on building their product

Plain employs highly capable engineers. Given the time and resources, they could have deftly spun up their own real-time analytics backend to support their in-product reporting features.

But that ran counter to their ethos: to focus on building a useful product. Plain has a commercial engineering team with a commercial focus, and while building an analytics service would likely be an enjoyable side project for their engineers, they wanted to remain focused on building a powerful customer support platform.

Tinybird: A "natural fit" for Plain

Plain's engineers quickly settled on Tinybird to provide the real-time data infrastructure they needed to build the features their customers wanted.

While they did consider a few alternatives - the BigQuery solution described above, a zero ETL AWS solution to Redshift, history tables in Postgres, etc. - all of these approaches only felt like a partial solution that would still require them to build added services and API layers to allow their application to interface with the analytics service.

Tinybird provided the tooling and infrastructure that Plain's engineers needed to build and scale an analytics API without setting up any infrastructure, maintaining any external ETLs, or writing any code beyond SQL. Tinybird handles data ingestion and load balancing, data storage and compute, and hosts Plain's analytics API via the dynamic REST endpoints that Plain's engineers can build in Tinybird.

Handling semi-structured data to give customers granularity

Plain allows its customers to define their own data model when analyzing their support. They can slice and dice their analytics by metrics and fields that are important to their business.

But offering such flexibility required Plain's engineers to think critically about how best to handle unstructured or semi-structured data.

Within Plain's event-driven architecture, anything that happens within Plain's system fires an event, which normally maintains the entire payload of the entity that changed. Whether it's a thread or a customer, the entire entity and its metadata get included in the payload.

When those events are fired, Plain uses a Lambda along with SQS to queue requests and send them to Tinybird via its Events API. Tinybird handles processing, load balancing, and writing those events into the underlying database.

Plain maintains raw tables in Tinybird, frequently adding new columns as new data models arise, and uses Tinybird's Pipes interface to massage and model the data in a way that makes sense to its customers. Once they're happy with the pipelines they've created, they simply publish them as dynamic REST endpoints that integrate with their frontend application.

Moving beyond in-product reporting

Plain has been able to ship a great in-product reporting experience very quickly thanks to Tinybird. But they don't intend to stop at just reporting.

Having Tinybird in their back pocket allows the engineers at Plain to think beyond just in-product reporting use cases and imagine other data-driven features, automations, personalizations, and workflows they could build on top of the data they already have. And with Tinybird, they don't need to worry about adding a new tool to their stack. They can work with a familiar interface to build new pipelines and APIs to support the real-time data features they need.

Regardless of what they end up building, Plain's engineers know that, with Tinybird, they can move fast. It took them just 4 weeks to ship their first feature to production after completing an initial proof of concept, and much of that time was spent on perfecting the design rather than creating and scaling data pipelines.

As they continue to discover new use cases, they'll lean on Tinybird to provide the performance, scale, and speed to quickly ship the data-driven features that their customers want.