Conversation
Highlights

Building Customer Success Organizations Four Times: Avi Avital’s Technical Playbook for Early-Stage Startups

Most CS leaders make their first hire within weeks. Avi Avital, VP of Customer Success at Nimble, waits three months—and spends that entire period doing support tickets and onboarding calls himself.

In a recent episode of The CX Front Lines, Avi shared his playbook for building customer success organizations from scratch at early-stage technical startups. He’s done it four times, each time joining at around $2 million in revenue with zero CS infrastructure. His approach rejects conventional CS wisdom: he hires technical experts who can write code before relationship managers, fixes onboarding for new customers before attempting to repair inherited accounts, and operates with an explicit 18-24 month timeline before CSMs become true revenue drivers.

The 90-Day Immersion: Building Institutional Knowledge Before Hiring

When Avi joins a company, his first quarter looks nothing like a typical VP onboarding. “It takes me about three months to make my first hire,” Avi explains. “In those three months I learned the product, the technology, I do onboarding, I do support myself.”

This isn’t executive hazing—it’s strategic immersion that informs every subsequent decision. By handling frontline work directly, Avi maps the actual technical complexity customers face, identifies which problems require deep product knowledge versus process, and determines the minimum skill floor his first hires need to own customer relationships without constant escalation.

The institutional knowledge built during these 90 days can’t be acquired through documentation review or product demos. When Avi writes job descriptions, designs interview assignments, and builds playbooks, he’s working from direct operational experience of what actually breaks in customer implementations and where CSMs will get stuck.

Python Scripts as Interview Assignments: Why Technical Depth Comes First

Avi’s early hiring decisions seem counterintuitive for a function typically associated with relationship building. “The hires I make in the first round of CSM are very technical,” he says. Early candidates at Nimble had to complete Python scripting assignments as part of the interview process.

The logic is structural, not preferential. “I inherit a portfolio of customers, there’s no support organization. And if I want to put some baseline in place, I need someone that will be able to own the customers and address their technical issues.”

When you’re selling to engineering teams and there’s no support function to escalate to, your CSMs need to independently diagnose and resolve technical problems. Hire relationship-focused CSMs in this environment and they’ll spend their days triaging issues they can’t solve, creating customer frustration and internal bottlenecks.

This technical hiring requirement persisted at Nimble for 2.5 years. Only recently did the profile shift. “Currently I’m hiring director of CSM and I’m looking to someone that has more commercial experience rather than technical,” Avi explains. “Initially they had to write Python script, now it’s not the requirement anymore.”

The timing of this shift isn’t arbitrary—it’s tied to specific organizational milestones. You need a support function to handle technical escalations. The product needs sufficient stability that CSMs aren’t constantly troubleshooting edge cases. Playbooks need to exist so commercial-focused CSMs can execute structured workflows rather than figuring out processes from scratch.

The Maturity Model: Staging KPI Evolution Over 18-24 Months

Avi operates with an explicit maturity model that he communicates upfront to both his team and company leadership. CSM responsibilities and success metrics shift through three distinct phases.

Early phase: Teams are necessarily reactive. “By nature more reactive because we have customers that we need to manage. We don’t have support so they will reach out and we haven’t established yet a relationship with the customer.” KPIs center on response time and resolution rates.

Middle phase: CSMs execute proactive playbooks around onboarding completion, adoption milestones, and renewal management. “Gradually I implement playbooks to manage the customer life cycle and I want to automate that and make sure that we capture that in the CRM the right way.”

Mature phase: CSMs own commercial outcomes. At Nimble, they now “own the entire life cycle of their customers, including renewal and extension,” with “targets on a quarterly basis, what are the expansion and on top of NRR, then NGR.” These aren’t yet enforced quotas—they’re expansion opportunities “driven by the CSM” who knows their book of business.

But Avi is explicit about timelines with founders. “It’s not going to happen in year one,” he tells CEOs who want CSMs generating revenue immediately. At Nimble, after 2.5 years of building infrastructure, “we’re probably 60% there” in the journey from technical troubleshooting to full account management.

The implementation detail: build KPI transitions into your quarterly planning. Early quarters measure support efficiency, middle quarters measure playbook execution rates, later quarters layer in commercial metrics. Communicate this progression explicitly so neither your team nor leadership expects commercial outcomes before the infrastructure exists to support them.

Fix Onboarding Forward: Why New Customers Get Priority Over Legacy Accounts

When inheriting a messy customer portfolio, the instinctive move is attempting to repair existing relationships first. Avi inverts this priority.

“That’s one of the first playbooks that I implement is the onboarding because it’s very hard to go back and fix an unmanaged relationship with the customer,” he explains. “So let’s start fixing it going forward with new customers that we are onboarding.”

The reasoning is both practical and strategic. Legacy customers without established success patterns are difficult to standardize—each relationship has unique technical debt, unclear success criteria, and no baseline for what “good” looks like. Attempting to systematize these accounts first burns time without creating repeatable processes.

Instead, implementing structured onboarding for new customers creates a cohort of well-managed accounts within 90 days. These become your reference base for expansion conversations, your case studies for marketing, and your proof points when demonstrating CS value internally. Meanwhile, legacy accounts remain in reactive mode temporarily but don’t block progress on building operational infrastructure.

The tactical implementation: month one, design your onboarding playbook with specific milestones and success criteria. Month two, deploy it with every new customer. Month three, use successfully onboarded accounts to demonstrate what properly managed relationships look like while gradually addressing the inherited portfolio.

Service Quality as Revenue Driver in Commoditized Markets

At Nimble, service quality isn’t a soft differentiator—it’s measurable revenue impact in their consumption-based model. Operating in what Avi describes as “a saturated market” for web scraping where “many customers are working with more than two vendors just for backup,” Nimble sees behavioral changes based purely on service quality.

“We see customers shifting more and more traffic to Nimble not because we are cheaper,” Avi explains. The underlying technology is comparable across providers. “But because they appreciate the service that my team is giving them.”

This manifests as customers increasing their usage and consumption with Nimble while maintaining relationships with other vendors for redundancy—but allocating less volume to competitors. In consumption-based pricing, this translates directly to revenue without requiring new logo acquisition.

The foundation Avi built for this comes from what he calls “value-based relationship”—a framework he wrote about years ago. “Back then there was lots of conversation on the importance of building relationship, which is absolutely true. But if the value is not there, relationship will take you so far.” The inverse also holds: delivering value without relationship building creates transactional dynamics that don’t drive preference in commoditized markets.

Three-Layer Automation: Data Infrastructure Before AI Implementation

As Nimble plans to double growth in 2026, Avi isn’t planning to double CS headcount. His approach involves three sequential infrastructure layers, and the ordering is non-negotiable.

“First of all making sure that we have the right data in place,” Avi explains. “Because automation will not work if you don’t have the right data in place. And then we built the automation on top of that and now the next level that we’re going to focus in 2026 is the support part.”

The specific sequence: Layer one is data infrastructure—ensuring usage metrics, health scores, and customer lifecycle data flow automatically into your CRM with proper data models. Layer two is alert-based automation—instead of CSMs “looking at dashboards all day long, I want them to get alerts when a significant signal should trigger some playbook.” Layer three, implemented only after the first two are solid, is AI for specific use cases like tier-one support.

Companies that jump to AI implementation without proper data infrastructure and automation get unreliable outputs. The tactical mistake: implementing AI chatbots for support when your knowledge base is incomplete, health scoring is manual, and usage data doesn’t update automatically.

Product maturity also determines timing. “If the product keep changing it will be hard for an AI to keep up with it,” Avi notes. “And I feel that for us at Nimble we are at the right stage” after 2.5 years of product stabilization.

Repositioning CS From Service Function to Revenue Organization

Avi made what he describes as “a conscious decision” to position himself as a revenue leader rather than a service leader. “I see a shift from being a service organization to a revenue organization,” he says. “And if I have one advice to CS leaders, no matter what stage of the company they’re going to join, you need to shift your mindset into becoming a revenue leader.”

This identity shift cascades through every aspect of org design. At Nimble, it meant building renewal and expansion tracking directly into Salesforce, giving CSMs visibility into expansion opportunities, and tracking quarterly targets for growth within existing accounts. “CSM identifying opportunities to expansion. We have targets on a quarterly basis, what are the expansion and on top of NRR, then NGR.”

The implications extend to compensation structure, team positioning within the company, and the profile of talent recruited. CS leaders who position as cost centers optimizing for customer satisfaction scores build fundamentally different organizations than those positioning as revenue drivers optimizing for net dollar retention and expansion ARR.

CS as a Temporary Organizational Structure

Avi holds a contrarian view on the permanence of CS as a function. “I do think that as the organization and companies grow and mature the CSM may be gradually shifting from CSM to account manager to a certain time that the organization completely dissolves into other functions.”

His evidence: “If you look at the true big companies in the tech world, Google, Apple, Microsoft don’t have CS organization or CSMs. It doesn’t mean that they’re not managing their customer at the highest level…but they have different and much more granular functions that are managing the entire life cycle of their customers.”

This suggests CS as currently structured may be a startup phenomenon—a necessary bundling of functions (technical support, relationship management, renewals, expansion) that eventually specializes and disperses as companies reach scale. For early-stage founders, this means building CS with evolution in mind rather than as a permanent organizational structure.

The playbook Avi has refined over four iterations isn’t prescriptive—it’s contextual. It stages organizational development based on real constraints (no support org, technical product, engineering buyers), matches hiring profiles to actual operational needs (technical depth before commercial skills), and maintains transparency about timelines (18-24 months from reactive support to revenue ownership). The sophistication isn’t in the tactics themselves but in understanding which capabilities must be built sequentially versus in parallel.