Conversation
Highlights

SOLO: How One CS Leader Rebuilt an Entire Post-Sale Operation While the Product Changed Under His Feet

When Isacc (Ike) Nelson joined SOLO three years ago, the company had a support problem that looked, on the surface, like a staffing problem. Multiple specialized teams handled different parts of the customer experience — each with its own hours, its own contact methods, its own way of doing things. Some teams worked Saturdays. Some didn’t. Customers navigating a billing issue, a technical configuration problem, and an account question could end up talking to three different teams on three different schedules, with no clear escalation path connecting any of them.

The instinct in most companies would be to hire more people, add more specialization, get better at the silos. Ike did the opposite. “Stripped all that down,” he said. “Combine that into a singular solution that’s tiered.”

That decision — consolidation before expansion — turned out to be the load-bearing move that made everything else possible.

In a recent episode of The CX Front Lines, Ike shared how he rebuilt SOLO’s post-sale operations from the ground up while the product itself was being fundamentally rearchitected, and what that process revealed about how CS organizations actually scale.

The Managed Service Trap

SOLO’s origins explain a lot about the problem Ike inherited. The company’s co-founders were knocking doors selling residential solar. They needed a tool to present proposals to homeowners and close deals faster, so they built one — and then kept building whatever customers needed. The development team operated more like a custom dev shop than a product organization, adding features on short cycles without a long-term roadmap.

The result was over 300 backend feature flags. Every customer had effectively been sold their own version of the product, configured to match their specific workflows, financing relationships, and regional regulatory requirements. That level of customization made the managed service feel premium. It also made scaling the platform nearly impossible.

When Ike joined to run account management, SOLO had just released self-serve configuration capabilities — the first step toward a true SaaS model. His job was to help customers make that shift while simultaneously rebuilding the post-sale infrastructure around a product that was still being transformed.

Consolidation as a Prerequisite, Not a Goal

The tiered support structure Ike built — T1, T2, T3, escalating into development — is standard SaaS architecture. What mattered wasn’t the structure itself but the sequence: he consolidated before he tried to scale anything else. Every downstream system he built, from feedback loops to customer advisory boards, depended on having a single, coherent escalation path underneath it.

Alongside the structural change, Ike built a customer journey map to identify where to focus first. He wasn’t using it to document the current state — he was using it as a prioritization tool, isolating the areas of highest friction and working through them systematically over three years. The map gave him a way to make transformation decisions that weren’t just reactive to whatever was loudest that week.

The other system he put in place early — and still runs today — is what he calls a top-10 bugs and feature list. “Top 10, I still call it a top 10 bugs and feature list, I still use that,” he said. The list feeds directly into product prioritization meetings, creating a closed loop between what CS hears from customers and what product actually builds. Most CS teams log feedback. Few close the loop in a way that’s structured enough to be defensible in a product meeting.

Challenging Customers Is a Retention Strategy

The harder problem wasn’t structural. It was human. Moving customers off 300 custom configurations meant telling them — directly — that the way they’d been operating needed to change. That’s a difficult conversation to have with customers who’d been promised flexibility as a feature.

Ike frames this through the lens of Radical Candor, Kim Scott’s framework built on caring personally and challenging directly. Most CS teams apply this internally. Ike applies it to customer relationships. “We need to challenge them to change their business a little bit, to operate in a more consistent way. That works well for them because we’ve proven it out and works well for us so we can actually manage and scale the platform.”

The distinction matters. A CS team that avoids difficult conversations with customers in the name of relationship preservation isn’t protecting the relationship — it’s accumulating technical debt in the form of unsustainable configurations. The willingness to challenge customers, grounded in genuine care for their outcomes, is what makes that conversation land rather than damage the account.

Usage as the Leading Indicator

On metrics, Ike is direct: the primary signal at SOLO isn’t NPS or CSAT. It’s volume. “Our mantra here recently has been volume is life,” he said. How frequently customers use the product, and how fluidly they move through it, tells the CS team more about retention risk than any satisfaction survey.

The reasoning is specific to SOLO’s use case. Their users — solar sales reps — generate proposals inside homeowners’ living rooms. A slow or clunky experience doesn’t just frustrate the rep; it disrupts the close in real time. “They don’t want to be blank. Stare with the homeowner for 15 minutes while they’re waiting for their proposal to get generated and be like, so, tell me about your dog.” Speed and usability aren’t product metrics at SOLO. They’re revenue metrics, and Ike treats them accordingly.

What the Transformation Actually Required

Three years after joining, SOLO is launching its first true self-serve SaaS feature — customers building their own designs and generating their own proposals without managed service support. The platform Ike inherited and the platform launching now are fundamentally different products serving the same customers.

What the transformation required wasn’t a better support team or a smarter feedback process, though both helped. It required building the infrastructure in the right order — consolidation first, feedback loops second, customer change management third — and being willing to have the hard conversations that most CS leaders defer until the relationship is already at risk.

The principle behind the tactic: you can’t scale what you haven’t simplified. Every CS leader inheriting a fragmented post-sale motion faces the same choice Ike faced. Add to the complexity or collapse it. The teams that scale are the ones that consolidate first.