Epoch

Epoch is a San Francisco-based employee experience platform that helps people teams plan, promote, and measure internal events and programs in one place. Founded by University of Waterloo alumni Jade Choy, Keith Choy, and Michael Miller, Epoch raised a US$3.6M seed round led by Rally Ventures. Their client list reads like a tech index: Salesforce, Datadog, Reddit, Duolingo, Instacart, and over 30 more companies using the platform to run thousands of internal events every month.

I joined as a Product Analyst. The title was originally CX & Data Reporting, but the scope of the work outgrew it quickly. My initial mandate was straightforward: create monthly feedback reports and quarterly business reviews for enterprise clients. But the team was small, the product was growing fast, and the role expanded into automation, product demos, feature launches, and eventually sales outreach.

What made Epoch interesting was the breadth. In a single week, I might write SQL to pull participant metrics for a Salesforce QBR, coordinate with engineering to optimize an expensive database query, set up community channels for a new Datadog launch, and walk into an office in San Francisco with branded swag to pitch a prospect in person. The role touched every part of the business.

The core of my work at Epoch was the client reporting pipeline. Every month, enterprise clients received a Feedback Report summarizing how their employees engaged with internal events. Every quarter, they received a comprehensive Business Review. These weren't templated PDFs. Each report was custom-built from multiple data sources and tailored to the client's specific program.

I created 40+ Feedback Reports over the term. Each FBR required pulling data from three different sources: SQL queries through Retool for participant counts and unique attendees, the client's domain insights page for event-level engagement, and internal CX metric sheets for cross-referencing activation rates.

The reports included total and unique participants, the most popular events ranked by attendance, timezone breakdowns showing where employees were engaging from, and detailed feedback scores from post-event surveys. Every piece of feedback was transferred into the report so stakeholders could understand not just how many people showed up, but what they thought and how the events could improve.

Consistency mattered. I maintained strict naming conventions, formatting standards, and data validation across every report. When a new co-op would eventually inherit this work, they needed to reproduce the same quality without reverse-engineering every decision I made.

I built 20+ Quarterly Business Reviews, each customized for the client. A QBR for Salesforce looked different from a QBR for Toast. Different metrics mattered, different time ranges were relevant, and each client had unique goals for their employee experience program.

The data came from everywhere. All-time activation rates from the CX metric sheet. Event trends and participation curves from SQL queries through Retool. Feedback response rates from the web app, which used Python to scrape through all events and calculate how many had feedback forms submitted. Each metric was sourced, verified, and placed into presentation slides with linked graphs that updated when the underlying data changed.

I maintained the CX Metrics Sheet, the internal source of truth for client health. Every week, I updated KPIs across all active accounts: activated accounts, unique participants, total employees, percentage of employees activated, total participants, and total events hosted.

The sheet used conditional formatting to track time-series changes, with green for increases and red for decreases, so anyone on the team could glance at it and immediately see which clients were trending up and which needed attention. I also cleaned up historical data that had accumulated inconsistencies from previous co-op handoffs, establishing a reliable baseline for future reporting.

After creating dozens of FBRs manually, the inefficiency became impossible to ignore. Every report followed the same structure, pulled from the same data sources, and required the same validation steps, but the process involved jumping between five different tools and manually copying data at every step.

I documented the entire FBR creation workflow end-to-end. Every step, every data source, every place where someone could make a mistake. The process looked like this: open Figma and duplicate last month's template, go to the client's domain insights page to find which events had feedback, switch to Retool and run SQL queries for participant data, cross-reference with the CX metric sheet for engagement numbers, transfer everything back into Figma with proper formatting, then export for Slack delivery.

Each report took 2–3 hours. Multiply that by 40+ clients per month and the reporting workload alone was consuming the majority of the CX team's time. The worst part wasn't the time. It was the error surface. Every manual copy-paste was a chance for a number to be wrong, a client name to be mismatched, or a timezone to be missed.

I partnered with engineering to centralize the entire FBR data pipeline into Retool. The first step was figuring out where each piece of data actually lived in the PostgreSQL database and writing queries that could replicate what we were doing manually across five different tools.

The queries needed to surface events with feedback responses, total and unique participants, response counts per event, timezone distributions, and engagement metrics, all filterable by client and date range. Some of these were straightforward. Others, like calculating total participants, were expensive operations that engineering handled with Python rather than raw SQL to avoid overloading the database.

The result was a single Retool dashboard where you could select a client, choose a date range, and get every metric needed for an FBR in one view. What previously took hours of context-switching across Figma, SQL, spreadsheets, and domain pages now took minutes. I also documented the entire dashboard and query logic in Confluence so future co-ops could extend or debug the system without starting from scratch.

Epoch used its own internal domain to demonstrate the product during sales calls. The problem was that it looked empty. Sparse event data, incomplete feedback, blank Insights pages. The demo domain didn't showcase what the product could actually do for a fully active enterprise client.

I created 50+ events on the demo domain, each with complete data across every field: feedback scores, estimated spend, spend per guest, target attendance, actual attendance, team involvement, and participating ERGs. These weren't placeholder entries. I simulated realistic participation patterns so the data told a coherent story when viewed across the platform.

I also RSVPed Epoch employees to events and created future events across multiple ERGs so the “Upcoming Events” section in the new Communities feature looked populated and engaging during demos. Every detail needed to feel like a real, active enterprise deployment.

With hundreds of new data entries flowing through the system, the Insights page on the demo domain transformed. Where it previously showed sparse charts and incomplete metrics, it now displayed rich participation trends, feedback distributions, and engagement patterns that the sales team could walk through with prospects.

The impact was immediate. Demo calls went from showing a partially empty product to showcasing a fully realized platform with data density that matched what enterprise clients would actually see. The sales team could now explain every feature with real-looking data behind it instead of describing what “would be there once you set it up.”

Epoch launched a new Communities feature that let enterprise clients organize employees into ERG-based groups within the platform. I was responsible for rolling this out to the first wave of enterprise clients.

Each Communities launch required direct coordination with the client. I worked with stakeholders at each company to understand their ERG structure: which communities they wanted, how employees should be grouped, and how the feature would fit into their existing workflow. Then I set up the communities on their domains, synced the correct employee groups, and ran admin training sessions to walk their people ops teams through the new functionality.

This wasn't just configuration work. It required understanding each client's organizational structure well enough to suggest the right community setup. Some clients had formal ERG programs with designated leads. Others had informal groups that needed to be structured for the first time. The onboarding had to account for both.

I launched Communities for 5+ enterprise clients, including Chime, Greenhouse, Datadog, and Moveable Ink. Each rollout followed the same general pattern but required client-specific customization: different community structures, different employee sync requirements, and different levels of admin familiarity with the platform.

The key to making these launches stick was putting clients in a position to succeed independently after the initial setup. By explaining the feature thoroughly and structuring their communities thoughtfully from the start, each client was able to move forward with adoption without ongoing hand-holding.

The role was scoped around data reporting, but I wanted to understand how the broader business worked. Halfway through the term, I started having coffee chats with the sales team to learn how Epoch approached client acquisition, and I asked to take on outbound work alongside my reporting responsibilities.

I built tailored outreach cadences through Salesloft, targeting accounts based on alignment between their internal programs and Epoch's features. The targeting was specific: companies that prioritized ERGs were strong fits for the Communities feature, companies with heavy Slack usage aligned well with Epoch's integration capabilities, and companies with distributed teams needed event management tooling the most.

I researched each target account: employee count, internal strategy, existing tools, and the specific value proposition that would resonate. I also did admin mapping work, scraping company domains and LinkedIn to identify the right stakeholders (typically people ops leaders) and understand their internal reporting structures so outreach went to the decision-maker, not a general inbox.

I took the initiative to do in-person drop-ins at offices in San Francisco. I went from office to office with Epoch-branded materials, looking to start conversations with people ops teams and internal event coordinators at target companies. The goal wasn't a hard sell. It was getting a foot in the door and creating awareness with the right people.

I also tapped my own network for referrals, connecting with people at target companies to find the right introduction path. This wasn't in the job description. I did it because I wanted to understand the full lifecycle of how a B2B SaaS company finds and closes enterprise customers, and the best way to learn was to do the work.

The work spanned reporting, automation, product, and sales, touching every part of the business over four months.