Eli Ahava

Sales Development Representative (SDR)

Orb

SDROutbound HeavyConsultative
Deal Size: N/A
Sales Cycle: N/A (SDR books meetings, doesn't close deals)
Posted by Eli Ahava•

Overview

You're an SDR at Orb, a usage-based pricing infrastructure platform. Your job is to book qualified meetings with SaaS companies (especially AI startups and growth-stage companies) that need to move from seat-based to usage-based pricing models. You'll spend most of your time doing cold outreach to technical founders, VP Finance, RevOps leaders, and engineering directors who currently hack together billing logic or struggle with existing systems.


Role Snapshot

AspectDetails
Role TypeOutbound SDR (booking meetings for AEs)
Sales MotionOutbound-heavy with some inbound from content/events
Deal ComplexityTechnical + financial buyer alignment
Sales CycleN/A (you book, AEs close)
Deal SizeN/A (infrastructure contracts vary widely)
Quota (est.)15-20 qualified meetings/month

Company Context

Stage: Series B (235 employees suggests growth-stage, well-funded)

Size: 235 employees

Growth: Actively hiring SDRs during market downturn, which suggests revenue momentum

Market Position: Category player in usage-based pricing infrastructure—competing against custom-built solutions and legacy billing systems. The "SaaSpocalypse" comment suggests they're positioned as the solution to a structural market shift.


GTM Reality

Pipeline Sources:

  • 70% Outbound - You're building most of your own pipeline through cold calls, emails, and LinkedIn to target accounts
  • 20% Inbound - Some hand-raisers from content, founder network, word-of-mouth in the PLG/AI community
  • 10% Events/Partnerships - Conference leads, integration partner referrals

SDR/AE Structure: Dedicated SDR team feeding meetings to AEs. You hand off qualified meetings but likely stay involved early in the cycle.

SE Support: Technical AEs or SEs likely handle deep product conversations—you need to understand the "why" (usage-based pricing shift) not the "how" (API implementation details).


Competitive Landscape

Main Competitors:

  • Stripe Billing (simpler but less flexible)
  • Custom-built solutions (engineering teams own billing logic)
  • Legacy billing systems (Zuora, Chargebee—not built for modern usage patterns)

How They Differentiate: Built specifically for usage-based models—handles complex metering, rating, and invoicing that engineering teams don't want to own. Targets modern software companies, not legacy enterprises.

Common Objections:

  • "We already built this internally" (engineering owns it)
  • "Stripe/Chargebee works fine for us"
  • "We're not ready to change pricing models yet"
  • "Too early—we'll revisit when we're bigger"

Win Themes:

  • Engineering teams shouldn't own billing logic (slows down product development)
  • Flexibility to experiment with pricing without code changes
  • Built for usage/consumption models, not retrofitted from subscription billing

What You'll Actually Do

Time Breakdown

Prospecting (60%) | Meeting Prep/Follow-up (20%) | Internal Syncs (20%)

Key Activities

  • Cold Calling: 50-70 calls per day to founders, finance, and RevOps leaders at SaaS companies. Most calls go to voicemail or get screened. You're leaving 30-40 voicemails daily. When you do connect, you have about 30 seconds to explain why usage-based pricing matters before they hang up or say they're not interested.

  • Email Sequences: Writing and sending personalized cold emails to target accounts. You're researching their pricing pages, LinkedIn posts about product launches, funding announcements to find an angle. Open rates are 20-30%, reply rates are 2-5%, and most replies are "not interested" or "circle back in 6 months."

  • LinkedIn Outreach: Sending connection requests and InMails to decision-makers. You're commenting on their posts about AI product launches or pricing strategy to build familiarity before pitching. Response rates are low—maybe 5-10% engage.

  • Qualification Calls: When someone agrees to chat, you're doing 15-20 minute discovery calls to figure out if they're actually evaluating billing infrastructure, who else is involved, what their timeline is, and whether they're a fit for Orb. You're listening for pain points: "Engineering is complaining about owning billing logic" or "We want to launch usage-based pricing but don't know how."


The Honest Reality

What's Hard

  • Cold outreach in a technical category: You're calling busy founders and finance leaders trying to convince them to think about billing infrastructure, which is rarely top-of-mind until it's broken. Lots of "we're good with what we have" responses.

  • Long sales cycles downstream: Even when you book a meeting, deals take 3-6 months to close. You won't see your booked meetings turn into revenue quickly, which can feel demotivating when you're grinding on activity metrics.

  • Technical enough to be credible: You need to understand usage-based pricing models, metering, billing infrastructure, and how this integrates with product/engineering workflows—but you're not an engineer. You'll get questions you can't answer and need to pull in AEs or SEs.

  • Gatekeepers and multiple stakeholders: You're rarely reaching the decision-maker on the first call. You'll talk to junior engineers, customer success, or operations folks who "might be interested" but don't control the budget. Getting to the actual buyer (VP Eng, CFO, Head of RevOps) takes persistence.

What Success Looks Like

  • Consistently booking 15-20 qualified meetings per month that progress to discovery/demo stages
  • High conversion rate from booked meeting → qualified opportunity (AEs accept your handoffs)
  • Building a pipeline of engaged prospects in your territory even if they're not ready to buy yet

Who You're Selling To

Primary Buyers:

  • Technical Founders / CTOs at Series A-C SaaS companies (especially AI/API-first products)
  • VP Finance / CFOs who own pricing strategy and revenue operations
  • RevOps / BizOps leaders managing billing, pricing, and systems

What They Care About:

  • Engineering velocity: billing logic slows down product development and requires ongoing maintenance
  • Pricing experimentation: ability to test and iterate on pricing models without engineering sprints
  • Revenue accuracy: correct metering, invoicing, and revenue recognition for usage-based models
  • Scale: current system breaks as usage volume grows (millions of events per day)

Requirements

  • Comfortable with high-volume cold calling and email outreach (60-80+ touches per day)
  • Ability to learn and explain technical concepts (usage-based pricing, metering, APIs) without being an engineer
  • Resilience: you'll hear "no" or get ghosted constantly—need to keep dialing
  • Curiosity about how modern software companies operate and monetize
  • Coachable: Eli mentions "high-standard, metrics-driven environment"—expect structure, accountability, and feedback
  • 0-2 years SDR experience (or smart, hungry, and willing to grind)