← Home

Compressing the Sales Cycle from 9 to 3 Months in Utility SaaS

How structured sales enablement -- battle cards, persona-specific pitch decks, and RFP-informed objection handling -- reduced Bynry's sales cycle by two-thirds.

Compressing the Sales Cycle from 9 to 3 Months in Utility SaaS

Strategic Context

This case study covers the sales enablement system I built at Bynry Corporation during my first stint (September 2021 to March 2024). The product was SMART360, an AI-enabled utility management platform. The sales cycle when I joined averaged approximately 9 months -- from first meaningful contact with a utility buyer to signed contract. For a bootstrapped startup burning cash, that timeline was existentially threatening.

I built the sales enablement function as part of my broader responsibilities as the sole marketing hire (eventually Marketing Manager, PMM & Growth). This was not a dedicated sales enablement role -- it was one piece of a much larger GTM mandate. But it was arguably the highest-leverage piece, because the fastest way to grow revenue at a startup is not to generate more leads but to convert existing leads faster.

The problem was structural, not just tactical. Utility SaaS sales involve multi-stakeholder buying committees, government procurement processes, and deeply risk-averse decision-makers. You cannot compress a 9-month cycle to 3 months by "following up faster." You compress it by ensuring that every conversation is substantive, every stakeholder gets the information they need without additional meetings, and every objection is addressed before it becomes a blocker. I am now back at Bynry as Product Growth Lead (since July 2025), applying these same principles at a more senior level with a more mature organisation.

The Problem

The 9-month sales cycle was not caused by slow decision-making alone. It was caused by information gaps. Each stage of the cycle had friction points where deals stalled because the right information was not available in the right format for the right stakeholder.

Technical evaluators stalled deals because they could not get clear answers about API integrations, data migration procedures, or security compliance without scheduling additional calls with the engineering team. Operations heads stalled deals because they could not visualise how daily workflows would change without a detailed walkthrough that mapped their current processes to SMART360. Procurement officers stalled deals because they lacked the documentation needed to justify a startup vendor to audit committees.

The sales team was spending an enormous percentage of their time creating bespoke materials for each deal. Every pitch deck was customised from scratch. Every technical question required pulling an engineer into a call. Every procurement question required the CEO to provide assurances about company stability. There was no reusable infrastructure.

The Approach

I built the sales enablement system around a principle I had derived from studying 100+ CIS and billing RFPs: every stakeholder in a utility buying committee has a specific set of concerns, and those concerns are remarkably consistent across organisations. If I could build materials that preemptively addressed the top 5-7 concerns of each stakeholder type, I could eliminate most of the back-and-forth that was stretching the sales cycle.

Battle cards. I created battle cards for the 4-5 most commonly encountered competitors. These were not feature comparison tables. Each battle card was structured around three scenarios: what to say when the prospect is currently using [competitor], what to say when the prospect is evaluating [competitor] in parallel, and what to say when the prospect raises [competitor] as a reason to delay a decision. The scenarios were informed by actual sales call recordings and prospect objections, not by marketing assumptions about what competitors' weaknesses were.

Persona-specific pitch decks. Instead of one pitch deck that tried to address everyone, I built modular decks that could be assembled based on who was in the room. The technical evaluator module focused on architecture, APIs, security, and migration. The operations module focused on workflow mapping and implementation timeline. The procurement module focused on TCO, compliance, and vendor stability. The sales team could combine modules as needed, ensuring that each presentation was relevant to the specific audience without requiring custom creation every time.

Objection handling library. I catalogued the most common objections from sales call recordings and developed structured responses for each. These were not scripts -- they were frameworks that gave the sales team the facts, context, and framing needed to address concerns confidently. The library was organised by stakeholder type and by stage in the sales process, because the same concern expressed at the evaluation stage requires a different response than the same concern expressed at the negotiation stage.

Self-serve technical documentation. For the technical evaluators, I worked with the engineering team to create a comprehensive technical documentation package that could be sent after the first call. API documentation, security compliance certificates, data migration guides, and integration architecture diagrams. The goal was to give technical evaluators everything they needed to complete their evaluation without scheduling additional calls.

What Worked (and What Didn't)

The self-serve technical documentation had the single biggest impact on cycle compression. Previously, technical evaluation was the longest stage of the process -- often 3-4 months on its own, driven by back-and-forth emails and scheduled calls to answer specific questions. After creating the documentation package, technical evaluation compressed to 4-6 weeks in most cases. Technical evaluators could work at their own pace, share documentation internally, and come to the next conversation with informed questions rather than basic discovery questions.

The battle cards were effective but required consistent updating. The utility SaaS market in India is evolving, and competitor positioning shifts. I built a quarterly review cadence for battle cards, but the reality was that competitive intelligence needed to be updated more frequently. The sales team flagged when a competitor changed their pricing or messaging, and I incorporated those updates in real time.

What did not work initially: the modular pitch deck approach. The first version had too many modules (8+) and the sales team found it confusing to assemble presentations. I simplified to 4 core modules -- overview, technical, operations, and commercial -- and adoption improved dramatically. The lesson was that sales enablement tools need to be simpler than you think they need to be. If the sales team has to make decisions about which materials to use, the materials are too complex.

What also required iteration: the objection handling library's format. The first version was a document -- long, searchable, but not something a salesperson would reference during a live call. I restructured it as a set of one-page cards (digital, optimised for mobile viewing) that could be quickly referenced during or just before calls. Usage increased immediately.

Results

The sales cycle compressed from an average of 9 months to approximately 3 months. This was not solely attributable to sales enablement -- the demand generation improvements meant leads were better-educated when they entered the pipeline, and the positioning work meant the product's value was clearer from the first interaction. But the sales enablement system was the direct mechanism that reduced friction at each stage of the buying process.

The 300+ MQLs generated by the demand generation engine converted more efficiently because the sales team had the tools to handle them properly. Without the enablement infrastructure, more leads would have meant more chaos, not more revenue. The enablement system created the capacity for the sales team to handle a growing pipeline without proportionally increasing the time spent on each deal.

The materials I built during this first stint continued to be used after I left in March 2024. When I returned to Bynry as Product Growth Lead in July 2025, the core architecture of the battle cards, modular decks, and objection handling library was still in place -- updated and evolved, but structurally the same system I had built. That durability is the strongest validation of the approach.

What I Learned

First, sales enablement is not about giving the sales team more materials. It is about giving them fewer, better materials that directly address the specific friction points in the buying process. Every document, deck, and card should be traceable to a specific question or objection that was causing deals to stall.

Second, the best source material for sales enablement is not marketing's assumptions about what buyers care about. It is sales call recordings and actual prospect conversations. The 100+ RFPs I studied were invaluable because they documented evaluation criteria in the buyer's own language. The sales team's recorded calls were equally valuable because they captured real-time objections and concerns.

Third, format matters as much as content. The objection handling library had good content from day one, but it was not useful until I reformatted it for how salespeople actually work -- quick reference during live conversations, not leisurely reading. Sales enablement that does not account for the user's context (time pressure, mobile access, mid-conversation reference) will not get used, regardless of how insightful the content is.

Related Case Studies

This sales enablement work was built on top of the positioning and messaging developed in the broader sales cycle compression programme. The MQLs that needed nurturing came from the content-led demand generation engine running in parallel.

Resume Contact