When we started Pequity, it was just my cofounder Warren, a few early teammates, and me — handling everything from customer requests to onboarding and sales. We wore every hat.
So when we closed our first round of funding, our instinct was to scale ourselves out of as many day-to-day tasks as possible. Our top priorities were clear: build and sell. But with our strong "customer-first" culture, we knew support couldn’t take a back seat.
That’s why early on, we brought in customer success and support. They were incredible — often stepping in to manually patch over product gaps while we built the features behind the scenes.
Can’t load data? Support will do it.
Can’t update a field? Ask support.
Approval didn’t map right? Support’s got it.
This worked — for a while. As our product matured and our customer base grew, it became clear that our support team was underwater. Customers had grown to rely on us in ways that didn’t scale. Support had to escalate bugs to engineers, gather more context from the customer, pass it back to engineers… rinse and repeat. Response times grew. Everyone felt the pain.
Our internal motto became: "Just fix it for them and we’ll figure it out later."
That held until Q4 of 2024. It was peak comp season, as August through February is our busiest time, and our team was treading water. Our roadmap was overloaded with customer requests, as was our support queue. It felt like everything was on fire.
That’s when we stumbled across a podcast where Parker Conrad (CEO of Rippling) reflected on his Zenefits days. He shared a lesson that hit us hard: Zenefits leaned too heavily on support to solve problems. In his newer companies, he embedded engineering at the front lines.
We were driving home from a family dinner when we heard that, and we just paused the podcast, stunned. He was describing us.
Our engineers were building what support couldn’t solve — but that meant the issues support was solving never got addressed at the root. We were stuck in a loop that didn’t scale.
So we called our team. It was time to change.
We introduced a new triage model with three support tiers:
Then we added engineers directly into the ticket queue as Tier 3 agents. One engineer would clean the queue daily and assign tickets into Jira. Engineers prioritized these Tier 3 tickets over any existing roadmap work.
We launched this new system in January 2025, right in the middle of our busy season. Risky? Sure. But if we wanted real change, we needed to feel the pain and solve the problems in real time.
At first, the engineers were shocked. "Why didn’t we know about this issue?" "Why didn’t anyone flag this sooner?"
The answer was simple: our support team had been too good at their jobs. They shielded the rest of the company from the mess — and as a result, the mess stayed messy.
But within weeks, we’d closed literally hundreds of Tier 3 tickets. Response times were within minutes to hours for our customers, delighting them. Engineers began shipping faster than ever. Everything from small delight features, key automations, and meaningful self-service updates; but the changes weren’t just in our product. We also saw our company and culture transform in several key ways:
Despite all this amazing improvement, we quickly realized there was more to do.
See, we had trained our customers to rely on us — so we leaned in further to scaling our self-service and support. We made it a rule: all requests had to go through support. For anything the customer could do, instead of doing the task for the customer, our support team took the time to explain the steps, send screenshots, and update documentation instead.
We also began forwarding small but painful UX issues to engineers — inconsistent headers, hard-to-find buttons, confusing logic — anything that slowed users down.
During all this, Warren and I stayed in the queue with the team, responding and triaging tickets ourselves. We learned more from that experience than from any dashboard or strategy doc. Our roadmap evolved in real time.
Then, it happened: a customer ran an entire comp cycle with zero support. They uploaded data, configured logic, added users, set permissions, ran the cycle, exported results, generated letters — all on their own.
This had never happened before. Every previous cycle had at least one ticket to support them.
It was the signal we’d been waiting for: we could scale.
Within weeks, two more customers ran cycles solo. We started doubling down on self-service, and the loop tightened. Our roadmap wasn’t just influenced by NPS surveys or feature requests — it was grounded in what customers were doing (and struggling with) in real time.
Now, six months later, we're building even smarter. We’re using the Tier 3 ticket data to power onboarding wizards, self-service guides, and AI agents trained on real customer experiences. Because our engineers were embedded in the queue, we’ve captured the exact troubleshooting steps that matter most — and that data is making our tools smarter every day.
It’s not rocket science. But it worked. And it’s why Pequity is now ahead on self-service, user experience, and responsiveness.
Our big takeaway? Building and selling will always be top priority. But if you want to innovate — truly innovate — your support team is your build team. And your engineers need to be on the front lines.
Maybe this isn’t right for every business. But for mine? Every future company I start will have engineers in the support queue from day one.