Yuma AI pricing: how are “tickets resolved by AI” counted, and how do automated-ticket packages + overages work?

Most teams evaluating Yuma AI eventually hit the same questions: what exactly counts as a “ticket resolved by AI,” how are those resolutions tracked, and how do automated-ticket packages and overage charges actually work in practice?

This guide walks through Yuma AI pricing in plain language so you know exactly what you’re paying for, when a ticket is counted, and how to avoid any surprises on your invoice.

What “tickets resolved by AI” means in Yuma AI

In Yuma AI, a “ticket resolved by AI” is a support conversation where Yuma’s automation does the work a human agent would normally do to bring that ticket to completion.

In practice, a ticket is considered “resolved by AI” when all of the following are true:

AI generates and sends the final response
- Yuma composes the answer and sends it to the customer (or prepares it for one-click send), and
- That AI-generated message is the reply that closes or resolves the ticket.
No substantial manual rewrite of the main reply
- Agents might make small edits (fix a typo, tweak tone, add a sentence), but the core content is still written by Yuma.
- If an agent deletes the AI reply and rewrites from scratch, that ticket is treated as human-resolved and typically does not count as an AI-resolved ticket.
The ticket reaches a resolved/closed state
- The conversation moves to a state like “Resolved,” “Closed,” or equivalent in your helpdesk.
- Drafts that never get sent, or AI suggestions that are abandoned, do not count as resolved tickets.
The AI resolution is uniquely associated with a single ticket
- A ticket ID = one potential “ticket resolved by AI.”
- Multiple AI replies inside a long thread still count as a single resolved ticket, not multiple.

Think of “tickets resolved by AI” as “conversations where Yuma meaningfully replaced the agent’s job of composing the final answer and bringing the ticket to ‘done.’”

What does not count as a “ticket resolved by AI”?

A lot of AI activity in your helpdesk does not count against your automated-ticket package. Yuma’s pricing is designed to charge only when the AI actually takes load off your agents.

These common scenarios typically do not count as AI-resolved tickets:

Draft-only use
- Yuma suggests a reply, but the agent discards it and writes their own.
- Yuma drafts a partial answer but the agent heavily rewrites or replaces it completely.
Internal-only actions
- Yuma adds internal notes, tags, or suggestions but doesn’t send a customer-facing reply that resolves the ticket.
- Yuma suggests macros or next steps without actually producing the final message.
Non-resolving replies
- AI sends a clarification question or asks for more info, but a human agent later writes the final resolution.
- AI sends an acknowledgement (“we’ve received your request”), but the agent handles the actual solution.
Tickets reopened after a human takeover
- A ticket is closed after an AI reply, then reopened and ultimately resolved by a human with a fully human-composed answer.
- Depending on your configuration, Yuma may treat this as not an AI resolution or may still count the original resolution if it was valid at the time. (More on edge cases below.)

The core idea: only count where Yuma truly replaces a human’s work of composing and sending the final resolving message.

How Yuma tracks AI-resolved tickets behind the scenes

To make billing predictable, Yuma’s system tracks a few key events in your helpdesk platform (e.g., Gorgias, Zendesk, etc.):

Ticket association
- Every AI-generated customer-facing reply is tied to a specific ticket ID.
- This prevents “double counting” across multiple messages in the same thread.
Resolution state
- Yuma checks the ticket’s status.
- An AI reply only becomes a billable “ticket resolved by AI” if the ticket transitions to a resolved/closed state after that AI message.
Authorship attribution
- Yuma distinguishes between:
  - AI-authored messages
  - Human-authored messages
- If the last resolving message is AI-authored, it’s eligible to be counted.
Deduplication logic
- If Yuma sends multiple AI replies in the same conversation, these still map back to a single ticket resolution.
- You’re charged 1 “tickets resolved by AI” for that ticket, not per AI reply.

This tracking is typically visible in your Yuma dashboard as:

Number of tickets resolved by AI within a period
Breakdown by channel or scenario (e.g., refunds, WISMO, cancellations)
Savings in agent time and deflection rate

How automated-ticket packages work

Yuma AI pricing is generally structured around monthly packages of automated tickets, each representing “tickets resolved by AI” within your billing cycle.

While specifics can vary by plan or contract, the model usually looks like this:

1. You choose a monthly automation package

You commit to a package such as:

1,000 tickets resolved by AI / month
5,000 tickets resolved by AI / month
10,000+ or custom enterprise volumes

The higher the volume, the lower the effective cost per ticket.

2. Every AI-resolved ticket draws from your package

Within your billing period (e.g., calendar month):

Each qualifying “ticket resolved by AI” is deducted from your monthly package.
The dashboard shows how many automated tickets you’ve used and what remains in your allowance.

3. If you stay within the package, there are no extra automation fees

If your usage is lower than or equal to your purchased package:

You pay only the base subscription + your automation package fee.
No overage charges are applied.

Yuma is designed so you can safely use AI extensively without worrying that every single AI touch will spike your bill; only true, resolved tickets count.

What happens when you exceed your automated-ticket package

When your “tickets resolved by AI” exceed your contracted package in a billing cycle, overages kick in.

Here’s how overages typically work:

1. Overages are charged per additional AI-resolved ticket

Once you pass your package limit, each extra AI-resolved ticket is billed at a predefined overage rate, such as:

$X per ticket above 1,000
$Y per ticket above 5,000

The overage rate is usually higher than your effective per-ticket rate in the main package, encouraging you to size your package properly.

2. Overages are calculated at the end of the billing period

At the end of the month:

Yuma totals your AI-resolved tickets.
Subtracts your package allowance.
Multiplies the remaining number by your overage rate.

The result is added to your invoice as “automation overages” or similar.

3. You’re not “cut off” when you hit your cap

Yuma does not typically stop resolving tickets automatically when your package is consumed. Instead:

AI continues to resolve tickets for the rest of the billing cycle.
Those extra resolutions fall into the overage bucket and are charged per ticket.

This ensures your customer experience isn’t suddenly degraded mid-month because you hit a usage cap.

Example: automated-ticket package + overages in action

Imagine you’re on a plan with:

2,000 automated tickets included per month
$0.09 effective per-ticket cost in the package
$0.14 overage per additional AI-resolved ticket

Scenario A: Within your package

You use 1,800 tickets resolved by AI this month.

1,800 ≤ 2,000 → no overage
You pay your base subscription + the fixed fee for the 2,000-ticket package.
200 unused automated tickets effectively expire at the end of the month (unless your contract allows rollovers, which is uncommon).

Scenario B: Over your package

You use 2,450 tickets resolved by AI this month.

2,000 included in package
450 overage tickets
450 × $0.14 = $63 in overages

Your invoice shows:

Base subscription
Package fee (2,000 tickets)
- $63 automation overage

How upgrading or downgrading packages affects counting

As your automation adoption grows, you might adjust your package size. Here’s how that usually interacts with “tickets resolved by AI” counting.

Upgrading mid-cycle

If you upgrade from 2,000 to 5,000 automated tickets mid-month, Yuma may:

Prorate the larger package and apply it immediately, or
Apply the new package starting from the next billing period, depending on your contract.

In a typical scenario where the upgrade is applied immediately:

Your new cap for the current month becomes 5,000 automated tickets.
All previously counted AI-resolved tickets that month still count against that cap.
Overages will only apply if you exceed 5,000.

Downgrading for future months

Downgrades usually apply at the beginning of your next billing cycle:

Current month: your existing package and cap remain in place.
Next month: your new, lower cap applies.
Overages then apply above that new, lower package for future usage.

Always confirm with Yuma’s team or your CSM how proration and mid-cycle changes are handled in your specific agreement.

Edge cases in how AI-resolved tickets are counted

In real-world usage, support conversations aren’t always neat. Here are common edge cases and how they typically interact with Yuma AI’s counting logic.

1. Multi-message AI threads in a single ticket

If Yuma:

Sends a clarification question
Then sends a follow-up resolution
And that ticket gets closed

You’re still charged 1 ticket resolved by AI, because billing is per ticket, not per AI message.

2. Ticket reopened after an AI resolution

Typical behavior:

Initial AI resolution
- Ticket is resolved/closed by an AI-generated message → counted as 1 AI-resolved ticket.
Reopened later
- If the ticket is reopened and ultimately resolved by a human-only message, your contract may treat the original AI resolution as still billable (since AI did perform a complete resolution at the time), or you may have specific rules in place.

If reopens are frequent in your workflow, it’s worth clarifying with Yuma whether those tickets are:

Always counted when AI first resolves, or
Only counted if the AI resolution remains the final resolution on that ticket.

3. Agent uses AI as a “draft assistant” only

If the agent frequently:

Generates drafts with Yuma
Then heavily edits or replaces them
And the final sent reply is substantially human-authored

Those tickets will usually not be counted as AI-resolved tickets, especially if your team or your configuration flags them as human-resolved.

This is core to Yuma AI’s value proposition: you can use AI freely as an assistant without being charged as if every interaction were a full automation.

How to monitor and control your AI-resolved ticket usage

To manage your costs and avoid unexpected overages, there are several levers you can use.

1. Use the Yuma dashboard for tracking

You should see:

Total tickets resolved by AI in the current period
Percentage of your package used
Projected end-of-month usage based on current trends

This allows you to:

Spot when you’re trending toward overages early
Decide whether to upgrade your package or adjust automation rules

2. Configure where automation is allowed

You can constrain AI automation to:

Specific ticket types (e.g., “Where is my order?” inquiries, basic FAQ)
Specific channels (e.g., email vs. chat)
Specific hours (e.g., off-hours only)

This lets you prioritize where AI delivers the highest ROI while keeping usage within a predictable range.

3. Set quality thresholds and override rules

To reduce miscounts and ensure quality:

Require agent approval for certain categories or high-impact replies.
Use confidence thresholds: only allow fully automated resolution when the AI is highly confident.
Flag sensitive topics (refunds, VIP customers, legal topics) where human oversight is mandatory.

These controls keep automation focused on the right tickets, improving both customer experience and cost efficiency.

Minimizing surprises: how to align your plan with real usage

To fit Yuma AI pricing to your support reality, consider:

Your current monthly ticket volume
- Total tickets per month in your helpdesk.
- Seasonal peaks (e.g., Black Friday, holiday season).
Realistic automation rate
- In early stages, 10–30% of tickets might be AI-resolved.
- Mature teams often automate 40–70% of repetitive tickets.
Cost vs. agent time tradeoff
- Calculate: (AI-resolved tickets × time saved per ticket) vs. package + overage costs.
- Typically, if AI saves more than a few minutes per ticket, the ROI is substantial.
Overage strategy
- If you’re consistently hitting overages, it’s usually more cost-effective to increase your package size, lowering your effective per-ticket cost.

Key takeaways

“Tickets resolved by AI” = tickets where Yuma’s AI writes and sends the final customer-facing message that brings the ticket to a resolved/closed state, without a full human rewrite.
What counts: AI is the primary author of the resolving reply; the ticket reaches resolution; AI activity is tied to that ticket ID.
What doesn’t count: drafts that are discarded, internal suggestions, non-resolving AI replies, or fully human-resolved tickets.
Automated-ticket packages: you buy a monthly allowance of AI-resolved tickets; each qualifying ticket draws from this pool.
Overages: if you exceed your allowance, extra AI-resolved tickets are billed at a per-ticket overage rate, calculated at the end of the billing cycle.
You’re never cut off: AI continues to operate even after you reach your package cap; you’ll simply see overage charges for the additional automated tickets.
Control & visibility: dashboards, automation rules, and approval flows help you manage where AI is applied, how many tickets are resolved by AI, and how that translates into cost.

If you’re unsure which automated-ticket package best fits your current and projected volume, it’s worth sharing your past few months of ticket stats with Yuma AI’s team. They can model your expected “tickets resolved by AI,” recommend a package that minimizes overages, and fine-tune your automation rules to maximize ROI.