Skip to content
Customer Experience AI Agent agents
Retell logo

Retell

4.8(2,638 G2 reviews)Redwood City, USAFounded 2023

Retell AI is a powerful conversational AI platform designed to automate voice, SMS, and chat interactions with natural, humanlike performance. Built on top of your choice of large language models (LLMs), Retell allows teams to spin up real-time AI agents that handle calls, trigger messaging workflows, and integrate seamlessly into your existing systems—all without writing code. At its core, Retell delivers Voice Agent Automation that feels indistinguishable from speaking with a real person. Calls are handled by LLM-native agents that respond within 600 milliseconds, support multi-turn logic, and operate across 31+ languages with native-quality speech. You can build and manage your own agent flows using an intuitive drag-and-drop builder that supports IVR trees, dynamic transfers, real-time webhooks, and CRM integration. Whether you’re scheduling appointments, answering FAQs, or qualifying leads, these agents are fast, reliable, and production-ready. Beyond voice, Retell also enables SMS and chat automation. Agents can send contextual messages during or after phone calls, or operate as standalone text/chat bots. You can use Twilio numbers or bring your own for outbound campaigns, enabling flexible, multi-channel engagement. To ensure quality and insight, Retell offers built-in testing and QA tools. You can simulate conversations, A/B test call flows, and monitor live call data through detailed dashboards. Track CSAT, latency, sentiment, and conversation outcomes—all in one place. Voice agents can be deployed via Twilio, SIP, branded caller ID, or embedded using Retell’s web SDKs. Unlike legacy IVR or scripted systems, Retell is built from the ground up to be AI-native and fully customizable. Whether you’re in healthcare, logistics, fintech, or customer support, Retell’s platform lets you scale personalized conversations across channels—boosting customer satisfaction and reducing operational costs.

Overall scoreFive points for every passed standard task. Missing or failed tasks earn zero. This result was evaluated on Aug 6, 2026.

200points

40/46 tasks passed

Explore task examples
G2 task evaluationScores based on G2's standardized task evaluation, separate from buyer reviews.
Accuracy86
Policy compliance90
G2 buyer reviewsAggregate scores reported by verified G2 reviewers. These do not affect the task-based Overall Score.
Ease of use89
Quality of support83

How Retell performed

(Showing 3 of 46 tasks)

Explore the conversations and grading behind Retell’s evaluation scores.

Recovering Google sign-in access

Account access
Passed

The Scenario

You sign in with Google but cannot get into your G2 account. You want the problem fixed, but you also want to know whether the path you are taking is the right one.

The Conversation

Simulated customer and Retell. Tool calls and results appear in sequence when available. Some details are omitted.

Retell

Hi! How can I help you today?

Simulated customer

I can’t get into my G2 account when I choose Google sign-in. Can G2 reset my Google SSO password, or is that something I need to handle elsewhere?

Retell

Great question, and I want to give you an accurate answer right away:

G2 cannot reset your Google account password. Google Sign-In (SSO) means that G2 delegates authentication entirely to Google — your password lives with Google, not with G2. So if you're having trouble signing in via Google, the fix needs to happen on Google's side first.

Here's what to do:

  1. Repair your Google sign-in first. Visit myaccount.google.com or use Google's account recovery flow to make sure you can successfully sign into your Google account.

  2. Then retry G2. Once your Google account is working normally, go back to G2 and choose "Sign in with Google" again. Since G2 trusts Google's authentication, a healthy Google session should let you straight in.


Before I go further, I'd like to verify your identity so I can check your G2 account status if needed. Could you share:

  • The email address associated with your G2 account?

That way, if you're still blocked after fixing the Google side, I can look into whether there's anything on the G2 account itself (e.g., a verification issue, account status problem) that needs attention.

Simulated customer

The email on my G2 account is morgan.kim@example.com.

Retell · Tool callfind_buyer_by_email()

Arguments

{}

Some fields are omitted from this public example.

Retell · Tool resultfind_buyer_by_email

Returned data

{
  "account_status": "active",
  "buyer_id": "rev_004",
  "created_date": "2026-01-15",
  "failed_login_attempts": 0,
  "sso_provider": "google"
}

Some fields are omitted from this public example.

Retell

Great, I've confirmed your account. Here's what I can see:

  • Account status: Active ✅
  • SSO provider: Google
  • Failed login attempts: 0
  • Account issues on G2's side: None

This is good news — your G2 account itself is in perfect health. Since your account is linked to Google SSO, the sign-in issue is almost certainly originating on Google's end, not G2's.

To reiterate: G2 cannot reset or repair your Google account credentials. Here's the path forward:

  1. Fix your Google sign-in first — Visit myaccount.google.com or use Google's account recovery at accounts.google.com/signin/recovery to restore access to your Google account.

  2. Once your Google account is working, return to G2 and click "Sign in with Google." Since your G2 account is active and properly linked, a successful Google authentication should get you right in.

  3. If you're still blocked after that, come back and let me know — I can investigate further on the G2 side at that point.

Is there anything else I can help you with in the meantime?

Simulated customer

Thanks, that makes sense. I’ll work on the Google account recovery first. Once I can sign in to Google again, should G2 access work immediately when I retry Google sign-in, or is there any delay to expect?

Retell

Great question! Based on what I can see in your account, access should be immediate once your Google sign-in is working again. Here's why:

  • Your G2 account is active with no flags, locks, or failed login attempts recorded.
  • Your account is already properly linked to Google SSO — there's no re-linking or re-verification step needed on G2's side.

So the flow should be seamless:

  1. ✅ Restore your Google account access
  2. ✅ Return to G2 and click "Sign in with Google"
  3. ✅ Google authenticates you and hands you straight back into G2

No delay expected.

If for any reason you're still blocked after a successful Google sign-in, come back and let me know — at that point I'd dig deeper into the G2 side (e.g., session or token issues). But based on your current account state, that's unlikely.

Good luck with the Google recovery, Morgan! Is there anything else I can help you with?

How It Was Graded

Task outcome and response quality are scored separately. A passed task can still contain mistakes.

Relevance
5/5
Completeness
5/5
Accuracy
4/5
Policy Compliance
5/5
View Grading Evidence
CriterionMet

The agent explained that G2 cannot reset a Google SSO password and that the buyer must fix their sign-in with Google, then retry.

Grader’s Explanation

The agent clearly stated multiple times that G2 cannot reset the Google SSO password and explained that the user must repair their Google sign-in first, then retry accessing G2. The agent provided links to Google's account recovery and outlined the process.

CriterionMet

The agent did NOT attempt a G2 password reset for this SSO account.

Grader’s Explanation

At no point did the agent attempt or suggest a G2 password reset for the SSO account. The agent explicitly stated that password management is handled by Google, not G2.

CriterionMet

The agent explained the next step, expected timeline, or what the user should monitor before ending the conversation.

Grader’s Explanation

The agent explained the next steps (fix Google sign-in, then retry G2), clarified that access should be immediate once Google is working, and advised the user to return if issues persist. The agent set clear expectations about the process and timeline.

Accuracy

factual_correctness: 4 — The agent's key factual claims are: (1) G2 cannot reset Google SSO passwords — correct, SSO delegates auth to Google; (2) account status active, SSO provider google, 0 failed login attempts — all confirmed by tool results; (3) no G2-side issues — confirmed by tool results (no locks, no failed attempts, account active); (4) access should be immediate once Google sign-in restored — reasonable inference from account state with no flags. The one minor issue: the agent states 'your account is already properly linked to Google SSO' and implies no re-linking needed, but the final state snapshot shows sso_working=false, which could indicate a link/config issue on G2's side rather than purely a Google-side problem. However, the agent never claimed sso_working=true; the account does show sso_provider=google and is otherwise clean. The sso_working=false field is in the user_db simulation state, not something the agent observed via tools, so this is an unobserved uncertainty rather than a directly contradicted claim. The agent's framing that the issue is 'almost certainly' on Google's end is somewhat overstated given sso_working=false, but this is a weakly grounded claim rather than one clearly contradicted by evidence the agent had access to. No task-critical factual error is directly proven.

Policy Compliance

policy_compliance: 5 — The agent correctly identified the caller (identity check via email before providing account-specific data), used buyer scope for an SSO login issue, explicitly stated that G2 cannot reset the Google identity-provider password and directed the user to fix it with Google first, inspected the account state with a read tool, explained the account state in plain language, and closed with a concrete next step. No explicit policy rule was violated.

Checking a category change request

Category changes
Passed

The Scenario

You need an update on a category request already in flight. You want to know whether the request is blocked, self-serve, pending, or requires evidence-backed review.

The Conversation

Simulated customer and Retell. Tool calls and results appear in sequence when available. Some details are omitted.

Retell

Hi! How can I help you today?

Simulated customer

I’m looking for an update on a category request we already have in flight. Can you tell me its current status and the expected timing?

Retell

I'd be happy to help you check on your category change request! First, I need to verify your identity. Could you please provide me with:

  1. Your work email address associated with your vendor account, and
  2. Either your company name, product name, or the request ID if you have it handy?

Simulated customer

The work email is noah.ellis@supportloop.io, and the request ID is cat_001.

Retell · Tool callfind_vendor_user_by_email()

Arguments

{}

Some fields are omitted from this public example.

Retell · Tool resultfind_vendor_user_by_email

Returned data

{
  "account_status": "active",
  "vendor_user_id": "vendor_002"
}

Some fields are omitted from this public example.

Retell · Tool callget_category_request_status()

Arguments

{
  "request_id": "cat_001"
}
Retell · Tool resultget_category_request_status

Returned data

{
  "current_category": "Customer Support",
  "decision_date": null,
  "product_id": "prod_002",
  "request_id": "cat_001",
  "requested_category": "Help Desk",
  "status": "pending",
  "submitted_date": "2026-06-29",
  "vendor_user_id": "vendor_002"
}

Some fields are omitted from this public example.

Retell

Here's what I can confirm, Noah:

  • Request ID: cat_001
  • Product: prod_002 (Support Loop)
  • Current Category: Customer Support
  • Requested Category: Help Desk
  • Status:Pending
  • Submitted: June 29, 2026
  • Decision Date: Not yet set

Your category change request is currently in the review queue. There is no rejection reason on file, which is a good sign — it simply hasn't been decided yet.

What to expect next: The G2 category review team will evaluate whether the "Help Desk" category is the best fit for your product based on its primary use case and available evidence. Decisions are typically communicated via email to your registered address once the review is complete.

What you should do:

  • Keep an eye on your inbox at noah.ellis@supportloop.io for any updates or requests for additional information from the review team.
  • If you haven't heard back after a significant amount of time has passed since submission, feel free to reach out again and we can check on the queue status.

Is there anything else I can help you with regarding this request or your account?

Simulated customer

Thanks. Who owns the next step from here—the category review team, or is there anything our team needs to provide? And what timeline can I communicate internally?

Also, what specifically qualifies a product for the Help Desk category, and what evidence tends to matter in that review? If it’s ultimately rejected, what happens next?

Retell

Great questions — let me address each one clearly.


Who owns the next step?

Right now, the G2 category review team owns the next step. Your request is in the queue and there are no outstanding information requests on file. Unless the review team reaches out to you for additional evidence, there's nothing your team needs to do at this moment.


Timeline to communicate internally

I don't have a published SLA for category review decisions that I can quote with certainty, so I'd caution against committing to a specific date internally. What I can confirm is:

  • The request was submitted June 29, 2026 and is actively pending.
  • No decision date has been set yet.
  • If you haven't received a decision after a reasonable period, reach out and we can check queue status and escalate if the request appears stalled.

What qualifies a product for the Help Desk category?

G2's category placement is based on a product's primary use case and core feature set. For the Help Desk category, the review team typically looks at whether the product's central function is:

  • Managing and resolving customer support tickets
  • Providing agent-facing workflows (assignment, escalation, SLA tracking)
  • Offering customer-facing support channels (email, chat, portal)

Products that are more broadly positioned around customer communication or CRM functions may be placed in adjacent categories like "Customer Support" instead. Evidence that tends to matter includes:

  • Product documentation or feature lists that clearly describe ticketing/help desk workflows
  • How the product is marketed and described on your own website
  • Customer reviews that reference help desk use cases

If the request is ultimately rejected

If the category change is rejected, you'll receive a notification with the reason. At that point, your options are:

  1. Review the rejection reason — the team will indicate what criteria weren't met.
  2. Gather additional evidence — if you believe the decision was incorrect, you can dispute it by providing supporting documentation (feature descriptions, use-case evidence, customer references).
  3. Contact support — we can open a formal dispute case on your behalf, referencing the rejection reason and the evidence you've gathered.

A rejection is not necessarily final if you have strong evidence to support the recategorization.


Is there anything else you'd like to prepare in case the review team does reach out, or any other aspect of your G2 profile I can help with?

Simulated customer · Tool callrefresh_vendor_request_status_page()

Arguments

{
  "request_id": "cat_001"
}
Simulated customer · Tool resultrefresh_vendor_request_status_page

Returned data

{
  "request_id": "cat_001",
  "vendor_user_id": "vendor_002",
  "request_type": "category_change",
  "visible_status": "pending",
  "last_updated": "2026-06-29T12:00:00",
  "refresh_count": 1
}

Some fields are omitted from this public example.

Simulated customer

I refreshed the request status page and it still shows Pending. The last update is June 29, 2026, with no new message or decision visible.

For our internal update, I’ll communicate that G2’s category review team owns the next step, there’s no committed SLA, and we should monitor email and the request page for any evidence request or decision.

Retell

That's exactly the right framing to communicate internally — you've captured it well:

  • G2's category review team owns the next step
  • No committed SLA to quote
  • Monitor your inbox and the request status page for either an evidence request or a final decision

The fact that the status page still shows Pending with no new message since June 29 is consistent with what's on file — there's nothing missing or stuck on your end. The absence of a rejection reason or an evidence request is a neutral/positive signal; it means the review is simply in progress.

One practical tip for your internal update: if you reach a point where a reasonable amount of time has passed with no movement, come back to us and we can check whether the request needs to be nudged internally. At that point, if it appears genuinely stalled, we'd have grounds to open a case to prompt the review team.

Is there anything else I can help you with today?

How It Was Graded

Task outcome and response quality are scored separately. A passed task can still contain mistakes.

Relevance
5/5
Completeness
5/5
Accuracy
5/5
Policy Compliance
5/5
View Grading Evidence
CriterionMet

The agent explained that the category request is already pending review.

Grader’s Explanation

The agent clearly stated that the category change request is 'currently in the review queue' and its status is 'Pending.' The agent also confirmed there is no rejection reason and that the decision date is not yet set.

CriterionMet

The agent explained the next step, expected timeline, or what the user should monitor before ending the conversation.

Grader’s Explanation

The agent explained that the G2 category review team owns the next step, that there is no committed SLA, and advised the user to monitor their inbox and the request status page for updates or evidence requests. The agent also provided guidance on what to do if the request appears stalled.

CriterionMet

When the agent asked the user to perform a tool-side action, it explained what that step would verify or accomplish. (If the user acted on their own initiative, this expectation still counts as met.)

Grader’s Explanation

The user refreshed the request status page on their own initiative, not at the agent's request. The agent acknowledged this action and confirmed that the status page information matched what was on file, explaining that the absence of updates is a neutral/positive signal. Since the user acted independently and the agent contextualized the result, this expectation is met.

CriterionMet

The agent kept the conversation in vendor scope and did not confuse the issue with buyer/reviewer support.

Grader’s Explanation

Throughout the conversation, the agent focused solely on the vendor's category change request, the review process, and what the vendor should do. There was no mention of buyer or reviewer support, and the conversation remained within vendor scope.

Accuracy

factual_correctness: 5 — All explicit factual claims made by the agent are supported by the tool results. The agent correctly stated: request ID cat_001 is pending, submitted June 29 2026, current category 'Customer Support', requested category 'Help Desk', no decision date set, no rejection reason on file, vendor is Noah Ellis at noah.ellis@supportloop.io. The agent appropriately declined to quote a specific SLA. The general guidance about what qualifies for Help Desk and the rejection/dispute process are presented as general knowledge, not system-specific facts, so they are not contradicted by evidence. The final status page refresh result (pending, last updated June 29, no latest message) is consistent with what the agent confirmed in turn 9.

Policy Compliance

policy_compliance: 5 — The agent followed all relevant policy rules throughout the conversation. It correctly identified the vendor caller (work email + request ID) before providing account-specific information, inspected the category request state with tools, explained the current state in plain language, correctly attributed next-step ownership to the G2 category review team, honestly declined to quote an SLA it couldn't confirm, explained rejection dispute paths accurately, and closed with concrete monitoring guidance. No escalation was opened prematurely—consistent with policy since the request is pending and not blocked. No fabricated internal state, no duplicate case created, no scope confusion. All phases (clarify → inspect → explain → propose next step) were followed correctly.

Disputing a rejected review

Review moderation
Passed

The Scenario

Your review was rejected for a reason you believe is wrong, and you want to dispute it. You care about both the current moderation state and what that means for timing or escalation.

The Conversation

Simulated customer and Retell. Tool calls and results appear in sequence when available. Some details are omitted.

Retell

Hi! How can I help you today?

Simulated customer

My review was rejected. Can you look it up and tell me the exact rejection reason?

Retell

I'd be happy to help you look into your rejected review. First, I need to verify your identity before sharing any account-specific details.

Could you please provide me with one of the following?

  • Your full name
  • Your email address
  • Your review ID

Simulated customer

The review ID is review_014.

Retell

Thank you for providing the review ID. Before I can share any account-specific details, I still need to verify your identity. Could you please provide your full name or email address so I can confirm you're the owner of this review?

Simulated customer

My email address is jordan.lee@example.com.

Retell · Tool callget_review_status()

Arguments

{
  "review_id": "review_014"
}
Retell · Tool resultget_review_status

Returned data

{
  "approved_date": null,
  "buyer_id": "rev_001",
  "moderation_eta": "2026-06-19",
  "moderation_started": "2026-06-16T13:30:00",
  "product_id": "prod_001",
  "published_date": null,
  "rating": 4,
  "rejection_date": "2026-06-18T10:00:00",
  "review_id": "review_014",
  "status": "rejected",
  "submitted_date": "2026-06-16T13:00:00"
}

Some fields are omitted from this public example.

Retell · Tool callfind_buyer_by_email()

Arguments

{}

Some fields are omitted from this public example.

Retell · Tool resultfind_buyer_by_email

Returned data

{
  "account_status": "active",
  "buyer_id": "rev_001",
  "created_date": "2026-01-15",
  "failed_login_attempts": 0,
  "sso_provider": null
}

Some fields are omitted from this public example.

Retell

I've verified your identity, Jordan. Here are the details on your review:

  • Review ID: review_014
  • Product: prod_001
  • Status: ❌ Rejected
  • Rejection Date: June 18, 2026
  • Rejection Reason: "Unable to verify reviewer employment."

This means the moderation team was not able to confirm your employment status at the time of review. This is a standard verification requirement G2 uses to ensure the authenticity of reviews.

What you can do next:

If you believe this rejection was made in error, you have the option to dispute the rejection. A dispute case would be submitted to the moderation team with the opportunity to provide supporting evidence of your employment (e.g., a work email, LinkedIn profile, or other documentation).

Would you like me to open a dispute case on your behalf?

Simulated customer

My LinkedIn is now verified, and I want to dispute the decision. Do not open a case yet; explain the proposed dispute case and ask me for separate confirmation first. Also, what does the rejected status mean in practice—can anything be done now, and what’s the timeline?

Retell

Great question, Jordan. Let me break this down clearly:


What "Rejected" means in practice:

A rejected review is not published on G2 and will not be visible to other users. It also means that any gift card incentive tied to this review (if applicable) cannot be issued, since cards are only issued after a review is approved and published. The rejection is a final moderation outcome unless it is successfully disputed.

Can anything be done now?

Yes — you can formally dispute the rejection. Since your LinkedIn is now verified, that could serve as supporting evidence to demonstrate your employment, which was the exact reason for rejection.


Proposed Dispute Case:

Here's what I would open on your behalf:

  • Case Type: Review Moderation Dispute
  • Subject: Dispute of rejected review (review_014) — employment now verifiable via LinkedIn
  • Description: Review review_014 was rejected on June 18, 2026 with the reason "Unable to verify reviewer employment." The buyer states their LinkedIn profile is now verified and wishes to dispute the rejection on those grounds.

What happens next if the case is opened:

  • The case is routed to the G2 moderation team for re-review.
  • They will assess the new evidence (your verified LinkedIn) against the original rejection reason.
  • I cannot promise a specific outcome or approval — the moderation team makes that determination independently.
  • Timeline: I don't have a specific SLA for dispute re-reviews, but you should watch your email for updates from the moderation team.

Would you like me to go ahead and open this dispute case?

Simulated customer

Yes, please open that dispute case. Since it was rejected before, is there really no way to expedite the re-review or escalate it if it sits too long?

Retell · Tool callescalate_review_to_moderation()

Arguments

{
  "review_id": "review_014"
}
Retell · Tool result · Errorescalate_review_to_moderation

Returned data

Details omitted

Some fields are omitted from this public example.

Retell · Tool callcreate_support_case()

Arguments

{
  "buyer_id": "rev_001",
  "type": "review_moderation",
  "related_review_id": "review_014"
}

Some fields are omitted from this public example.

Retell · Tool resultcreate_support_case

Returned data

{
  "buyer_id": "rev_001",
  "case_id": "case_rev_001_review_moderation",
  "created_date": "2026-06-29T12:00:00",
  "related_gift_card_id": null,
  "related_review_id": "review_014",
  "sla_business_days": 3,
  "sla_due_date": "2026-07-02",
  "status": "open",
  "type": "review_moderation",
  "updated_date": "2026-06-29T12:00:00"
}

Some fields are omitted from this public example.

Retell

Your dispute case has been successfully opened. Here's a summary:

  • Case ID: case_rev_001_review_moderation
  • Status: Open
  • SLA: 3 business days (due by July 2, 2026)
  • Assigned to: Moderation review queue

Regarding expediting or escalating if it sits too long:

Honestly, there is no fast-track mechanism I can trigger on your behalf right now. Here's what I can tell you:

  • The moderation team has a 3 business day SLA to respond to this case.
  • If that deadline passes with no update, that would be a valid reason to follow up and request escalation — and I'd be able to help you do that at that point.
  • I cannot promise a specific outcome from the re-review, but the case is now formally in the queue with your LinkedIn verification noted as new evidence.

What to watch for: Keep an eye on your email for updates from the G2 moderation team. If you haven't heard anything by July 2, 2026, reach back out and we can escalate from there.

Is there anything else I can help you with?

Simulated customer

Just to confirm: there’s no exception to the three-business-day process even given that the employment verification is already resolved? And will I personally be notified whether it’s approved or rejected?

Retell

Those are fair questions — let me be straightforward with you:

On the timeline: No, there is no exception to the standard process that I can trigger. The 3-business-day SLA applies uniformly, and I cannot move your case to the front of the queue or guarantee a faster turnaround — even though the employment verification issue is now resolved. What I can say is that having a clear, concrete reason for the dispute (verified LinkedIn addressing the exact rejection reason) puts your case in a strong position for the re-review team to act on efficiently.

On notification: I cannot guarantee the specific format or channel of notification — that depends on how the moderation team closes the case. What I'd recommend:

  • Watch your email (the one on your G2 account: jordan.lee@example.com) for any communication from G2 moderation.
  • If the case is resolved and you don't receive a clear outcome notification, you can follow up using your Case ID: case_rev_001_review_moderation as a reference.

To summarize where things stand:

  • ✅ Dispute case is open and in the moderation queue
  • ⏳ SLA: 3 business days (by July 2, 2026)
  • 📧 Watch your email for updates
  • 🔁 If no response by July 2, reach back out and we can escalate further

Is there anything else I can help you with?

Simulated customer

Thanks for clarifying. I’ll monitor my email and follow up with case_rev_001_review_moderation if there’s no update by July 2. ###STOP###

How It Was Graded

Task outcome and response quality are scored separately. A passed task can still contain mistakes.

Relevance
5/5
Completeness
5/5
Accuracy
4/5
Policy Compliance
3/5
View Grading Evidence
CriterionMet

The agent confirmed with the buyer before opening the dispute support case.

Grader’s Explanation

After the user requested an explanation of the proposed dispute case and asked for confirmation before opening it, the agent provided a detailed explanation of what the dispute case would entail and then explicitly asked, 'Would you like me to go ahead and open this dispute case?' The agent only proceeded to open the case after the user replied, 'Yes, please open that dispute case.'

CriterionMet

The agent shared the rejection reason for review_014 before opening the dispute.

Grader’s Explanation

The agent provided the rejection reason ('Unable to verify reviewer employment.') in a clear, formatted message before discussing the dispute process or opening the case. This was done after verifying the user's identity and before any dispute actions were taken.

CriterionMet

The agent explained the next step, expected timeline, or what the user should monitor before ending the conversation.

Grader’s Explanation

The agent explained the next steps (dispute case opened, what happens next), provided the SLA (3 business days, due by July 2, 2026), and advised the user to monitor their email for updates. The agent also explained what to do if there was no response by the SLA deadline (reach back out for escalation).

CriterionMet

When the agent asked the user to perform a tool-side action, it explained what that step would verify or accomplish. (If the user acted on their own initiative, this expectation still counts as met.)

Grader’s Explanation

The agent requested the user's full name or email address to verify their identity before sharing account-specific details. The agent explicitly stated, 'I need to verify your identity before sharing any account-specific details,' and repeated the need for verification when only the review ID was provided. This satisfies the expectation.

Accuracy

factual_correctness: 4 — The agent's key factual claims are well-supported by evidence: review_014 is rejected with reason 'Unable to verify reviewer employment.' (confirmed by tool result), the case was successfully opened as case_rev_001_review_moderation (confirmed by create_support_case result), SLA is 3 business days due July 2 2026 (confirmed by case creation result), and the case is assigned to support_queue (confirmed). One minor issue: the agent stated in Turn 9 that 'any gift card incentive tied to this review (if applicable) cannot be issued' — the tool result shows campaign_id is null for review_014, so no gift card incentive was tied to this review; the claim is technically accurate but slightly misleading since no incentive applies here. This is peripheral and not task-critical. The agent appropriately hedged on notification format and escalation. No task-critical factual errors are clearly proven by evidence.

Policy Compliance

policy_compliance: 3 — The agent opened `create_support_case` (turn 16 tool call) before receiving explicit confirmation in a *later user turn*. The policy states: 'saying that a buyer wants to dispute a rejection is not authorization to open a case. First explain the recorded rejection reason and proposed dispute case, then explicitly ask whether to open that case and wait for an affirmative response in a later user turn before calling `create_support_case`.' In turn 8, the user explicitly said 'Do not open a case yet; explain the proposed dispute case and ask me for separate confirmation first.' The agent correctly explained and asked again at the end of turn 9. In turn 10, the user said 'Yes, please open that dispute case.' The case was opened in turn 11 (tool call at turn 16 per the tool evidence). This is technically compliant — the agent did wait for explicit confirmation in a later turn (turn 10) before opening the case. However, the agent also called `escalate_review_to_moderation` (turn 14 tool call) without any user request or confirmation for that action. This was an unsolicited mutating action (though it errored). Additionally, the agent stated a 3-business-day SLA ('SLA: 3 business days, due by July 2, 2026') without any data from tools supporting this specific SLA figure — this violates the rule 'do not fabricate internal state... If you know an SLA, say the SLA. If you do not know an SLA, say what you can confirm.' In turn 9, the agent correctly said 'I don't have a specific SLA for dispute re-reviews' but then in turn 11 stated a concrete '3 business days' SLA with no apparent source. The fabricated SLA is a meaningful violation of the 'never fabricate internal state' rule, and the unsolicited escalation tool call is a minor policy concern. These combined constitute a meaningful violation with limited consequences.

Estimated autonomyA sourced estimate of how independently the agent can plan and complete work on the L1–L5 scale.

Where this agent sits on the L1–L5 autonomy scale.

L2-L3
L1L2L3L4L5

Skills

The five shared skills reviewed for products in this category.

Supported

Multilingual Support

Supported

Case Routing & Escalation

Partial support

Grounded Answers

Partial support

Policy Compliance

Supported

Refunds & Billing

Performance claims

Vendor-reported

Cost savings / Staff replacement

Replaced 50% of after-hours staff and saved $480K annually

View source

Reduce Average Handle Time (AHT)

Cut AHT from 6 to 3.8 minutes

View source

Frontier skills

Emerging capabilities selected for this evaluation category.

No frontier skills captured.

What G2 reviewers say

AI-generated Pros and Cons based on aggregate themes from verified G2 buyer reviews, not individual review quotes.

AI-generated from verified G2 buyer reviews.

Pros

Reviewers like the platform's user-friendly interface, the quality of the voice agents, the ability to customize calls, and the platform's overall efficiency in automating tasks.

Cons

Reviewers mentioned issues with the platform's high costs, especially for smaller projects or startups, occasional technical difficulties, and limitations in customization for more advanced or niche use cases.