Forem: Kal Wiggins

Why Per-Seat Pricing for Support Tools is Bleeding Your SaaS Dry

Kal Wiggins — Mon, 19 Jan 2026 17:00:00 +0000

You know what's weird? Every developer tool prices differently—Stripe charges per transaction, Twilio charges per message, AWS charges per compute hour. But support software? Everyone charges per seat.

Zendesk, Freshdesk, Intercom, Help Scout—they all want $50-150/month for each person who can look at a support ticket. And we've just... accepted this?

Let me show you why this model is probably costing you way more than you think.

The Hidden Tax on Modern Dev Teams

Here's the thing about modern SaaS companies: support isn't a department anymore. It's everyone.

Who needs to see support tickets?

Engineers debugging reported bugs
PMs tracking feature requests
Founders responding to VIP customers
DevOps checking if outages were reported
Sales answering pre-purchase questions

Under per-seat pricing, each of these people needs a $79/month seat. Even if the PM touches 5 tickets a month. Even if the engineer just needs to see the stack trace someone pasted.

// What your costs look like
const team = {
  supportAgents: 3,      // These actually need it
  engineers: 4,          // Need occasional access
  productManagers: 2,    // Review feature requests
  founders: 2,           // VIP escalations
};

const seatsNeeded = Object.values(team).reduce((a, b) => a + b, 0);
const monthlyBill = seatsNeeded * 79;

console.log(`${seatsNeeded} seats × $79 = $${monthlyBill}/month`);
// 11 seats × $79 = $869/month

That's $869/month so your engineers can occasionally check if a bug was already reported.

The Workarounds Everyone Uses (And Why They're Worse)

When seats are expensive, teams get creative:

# The shared login approach (don't do this)
export ZENDESK_LOGIN=support@company.com
export ZENDESK_PASSWORD=hunter2
# "Just use the team account"

Shared logins - No audit trail, security nightmare, probably violates your SOC2 compliance.

Screenshot relay - Engineer: "Can you forward me that ticket?" Support: takes screenshot, pastes in Slack - Now you have context in three different places.

The human API - Support becomes a proxy layer between your team and customer feedback. Every escalation adds latency.

All of this operational overhead doesn't show up on your SaaS bill. But it's real.

Let's Talk Numbers

I'll run through three scenarios and you can see which one looks like your company:

Scenario A: Small SaaS (500 tickets/month)

Per-seat model:
  3 agents + 5 occasional users = 8 seats
  8 × $79 = $632/month
  Cost per ticket: $1.26

Per-ticket model:
  $29/month for 1,000 tickets
  All 8 users included
  Cost per ticket: $0.06

Delta: -$603/month (-95%)

Scenario B: Growing E-commerce (3,000 tickets/month)

Per-seat model:
  5 agents + 8 occasional users = 13 seats
  13 × $79 = $1,027/month
  Cost per ticket: $0.34

Per-ticket model:
  $99/month for 10,000 tickets
  All 13 users included  
  Cost per ticket: $0.03

Delta: -$928/month (-90%)

Scenario C: Agency with 20 clients (8,000 tickets/month)

Per-seat model:
  4 staff + 15 client contacts = 19 seats
  19 × $79 = $1,501/month
  Cost per ticket: $0.19

Per-ticket model:
  $99/month for 10,000 tickets
  All 19 users included
  Cost per ticket: $0.01

Delta: -$1,402/month (-93%)

The pattern is clear: the more people who need access, the worse per-seat pricing gets.

The AI Elephant in the Room

Here's where it gets really interesting. AI is changing support economics fast.

Let's say you implement an AI that handles 40% of your tickets automatically:

// Per-seat economics with AI
const ticketsBefore = 1000;
const ticketsAfterAI = ticketsBefore * 0.6; // AI handles 40%
const seatsNeeded = 8; // Still need humans for oversight
const perSeatCost = 8 * 79; // $632/month - UNCHANGED

// Per-ticket economics with AI  
const perTicketCost = 29; // Base tier still covers 1000
const actualCost = ticketsAfterAI < 1000 ? 29 : 29 + (ticketsAfterAI - 1000) * 0.02;
// Cost drops as AI handles more!

With per-seat pricing, your AI investment saves you nothing on software costs. You still need the same seats for human oversight and edge cases.

With per-ticket pricing, your costs actually decrease as AI handles more volume. The efficiency gains translate directly to savings.

When Per-Seat Actually Makes Sense

I'm not saying per-seat is always wrong. It can work if:

You have 1-2 users total - At that scale, $79/seat might be cheaper than a $99 base fee
Extremely high volume, tiny team - 100,000 tickets handled by 5 people
You need specific enterprise features - SSO, advanced workflows only available in legacy vendors

But honestly? Scenario 1 and 2 are pretty rare. Most companies have more people who should have support access than currently do.

The Operational Cost Iceberg

Here's what most cost comparisons miss—the hidden overhead:

                 What you see:
                 ┌──────────────┐
                 │ Software bill │ ← $632/month
                 └──────────────┘
  ─────────────────────────────────────────
                 What you don't:
          ┌─────────────────────────┐
          │  Escalation delays      │ ← Waiting for access
          │  Context handoffs       │ ← Explaining issues
          │  Slack threads about    │ ← tickets
          │  tickets not in         │ ← the ticket system
          │  Knowledge silos        │ ← Engineers miss patterns
          │  Customer frustration   │ ← "Let me check with..."
          └─────────────────────────┘

Studies show cross-functional tickets take 2-3x longer when access is restricted. If your average ticket costs $15 in labor and you add 30 minutes of coordination overhead, that's $7.50 per ticket in hidden costs.

TL;DR

Per-seat pricing charges for capacity, not usage. You pay the same whether someone handles 500 tickets or 5.
Modern dev teams have 3-4x more people who need support access than traditional "agents"
The workarounds (shared logins, screenshot relay, human proxies) add operational overhead that doesn't show on invoices
AI makes it worse—your per-seat costs stay flat while AI handles the easy tickets
Per-ticket pricing aligns with how dev tools should work: pay for what you use, not who might use it
Run the math for your team. Count everyone who should have access, not just who currently does.

Originally published at Dispatch Tickets. We're building an API-first ticketing system with per-ticket pricing—unlimited users included. Check it out if the per-seat tax is hitting your team.

Why I Stopped Using Traditional Helpdesks (And Built Support Into My App Instead)

Kal Wiggins — Tue, 13 Jan 2026 07:04:52 +0000

Every helpdesk I've used follows the same pattern: it's a separate app. Your users email support@company.com, tickets land in Some Other Dashboard™, and your team context-switches between your product and your support tool all day.

It works. But it's not great.

What if support tickets were just... an API primitive? Like Stripe for payments or Twilio for SMS, but for support tickets?

The "We Have An API" Lie

Most helpdesks claim to have APIs. They do—technically. But there's a difference between "we bolted an API onto our app" and "the API is the product."

Here's how you can tell the difference:

Bolted-on API:

API is read-heavy (pull tickets into your system)
Webhooks are an afterthought
You still need their UI for most workflows
Authentication assumes you're the only consumer

API-first:

API is the primary interface
Webhooks are first-class citizens
Their UI is just a client consuming the same API you do
Multi-tenant by design

What This Looks Like in Practice

With an API-first ticketing system, creating a ticket is just a POST request:

curl -X POST https://api.dispatchtickets.com/v1/workspaces/ws_xxx/tickets \
  -H "Authorization: Bearer your_api_key" \
  -H "Content-Type: application/json" \
  -d '{
    "subject": "Button not working on checkout page",
    "description": "User clicked Pay and nothing happened",
    "customer_email": "user@example.com",
    "priority": "high",
    "custom_fields": {
      "user_id": "usr_12345",
      "page_url": "/checkout",
      "browser": "Chrome 120",
      "error_log": "TypeError: undefined is not a function"
    }
  }'

See that custom_fields object? It takes any JSON. No predefined schema. No "please contact sales to add custom fields." Just pass whatever context is relevant.

The Cool Stuff This Enables

Once tickets are an API primitive, you can do things that traditional helpdesks make painful:

1. Automatic Ticket Creation from Errors

// In your error boundary or catch block
window.addEventListener('error', async (event) => {
  await fetch('/api/support/tickets', {
    method: 'POST',
    body: JSON.stringify({
      subject: `JS Error: ${event.message}`,
      description: event.error?.stack || 'No stack trace',
      custom_fields: {
        url: window.location.href,
        user_id: getCurrentUserId(),
        timestamp: new Date().toISOString()
      }
    })
  });
});

Your support team sees the ticket before the user complains.

2. In-App Support That Actually Has Context

Instead of "please describe your issue," you can pre-fill everything:

function SupportButton({ user, currentPage }) {
  const openSupport = () => {
    openTicketModal({
      prefill: {
        customer_email: user.email,
        custom_fields: {
          user_id: user.id,
          plan: user.subscription.plan,
          page: currentPage,
          recent_actions: user.activityLog.slice(-10)
        }
      }
    });
  };

  return <button onClick={openSupport}>Get Help</button>;
}

No more "what's your account email?" No more "can you send a screenshot?" The context is already there.

3. Build Support Into Your Admin Dashboard

Why make your team learn another app?

// In your existing admin panel
function CustomerDetail({ customerId }) {
  const { data: tickets } = useQuery(
    ['tickets', customerId],
    () => fetchTickets({ customer_id: customerId })
  );

  return (
    <div>
      <CustomerInfo id={customerId} />
      <OrderHistory id={customerId} />
      <SupportTickets tickets={tickets} /> {/* Same dashboard */}
    </div>
  );
}

Your ops team sees customer info, orders, and support tickets in one place. No tab switching.

4. Webhooks for Everything

When a ticket is created, updated, or resolved—you get a webhook. Build whatever you want:

// Your webhook handler
app.post('/webhooks/tickets', (req, res) => {
  const { event, ticket } = req.body;

  if (event === 'ticket.created' && ticket.priority === 'urgent') {
    // Page on-call engineer
    pagerDuty.trigger({
      summary: ticket.subject,
      source: 'support-ticket',
      severity: 'high'
    });
  }

  if (event === 'ticket.resolved') {
    // Update your CRM
    crm.updateContact(ticket.customer_email, {
      last_support_interaction: new Date(),
      tickets_resolved: increment(1)
    });
  }

  res.sendStatus(200);
});

The Pricing Thing

Traditional helpdesks charge per seat. Five agents? Five seats. But here's the thing—in a modern SaaS, everyone touches support sometimes:

Engineers triage bugs
PMs review feature requests
Founders reply to key accounts

Per-seat pricing punishes this. You either pay $79/month for someone who handles 3 tickets, or you create workarounds (shared logins, forwarding emails, Slack threads about tickets).

API-first systems tend toward usage-based pricing. Pay for tickets, not seats. Everyone can have access.

When Not to Use API-First

To be fair, API-first ticketing isn't for everyone:

Non-technical teams: If no one can write code, you need a full UI out of the box
Simple needs: If email-only support with 1-2 agents covers you, a traditional helpdesk is fine
Existing investment: If you've already built complex workflows in Zendesk, migration has a cost

But if you're building a SaaS product and you have developers on the team? There's no reason your support system should be less flexible than everything else in your stack.

TL;DR

Traditional helpdesks are apps with APIs bolted on
API-first ticketing means tickets are the primitive—build whatever you want
You can embed support in your product, not around it
Custom fields take any JSON (no schema limits)
Webhooks let you integrate with everything
Usage-based pricing means your whole team can have access

I'm building Dispatch Tickets—an API-first ticketing system designed for developers. If you're interested, we're doing early access right now.