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
| Aspect | Details |
|---|---|
| Role Type | Outbound SDR (booking meetings for AEs) |
| Sales Motion | Outbound-heavy with some inbound from content/events |
| Deal Complexity | Technical + financial buyer alignment |
| Sales Cycle | N/A (you book, AEs close) |
| Deal Size | N/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)