Jotform
Jotform AI Agents are automated real-time assistants designed to help your users at any time of day or night. AI Agents are the future of customer service. Train and customize your own personal AI Agent to enhance user engagement, improve response times, and streamline support operations. With Jotform’s intuitive, no-code AI builder, you can easily train and customize your own AI Agent to match your brand voice, support workflows, and respond with the exact information your users need. Simply provide key details, documents, FAQs, or form data, and your AI Agent will learn from this context to deliver accurate, personalized interactions. This level of customization helps teams improve response times, boost user satisfaction, and streamline support operations across every stage of the customer journey. One of the platform’s most powerful advantages is its extensive library of 7,000+ customizable AI Agent templates. These ready-made templates provide an easy starting point for a wide variety of use cases, including customer support, onboarding, lead qualification, appointment scheduling, product education, internal training, and more. Each template can be fully personalized with your own instructions, tone, workflows, and industry-specific knowledge—allowing you to deploy high-performing AI Agents in minutes. Jotform AI Agents provide 24/7 automated assistance, ensuring your customers receive instant support even outside of business hours. While you sleep, your AI Agents continue working—handling inquiries, resolving issues, collecting information, and providing accurate responses around the clock. This continuous availability reduces wait times, increases engagement, and helps teams keep up with growing demand. With multichannel support, Jotform AI Agents can operate wherever your users are. Deploy your agents across web, chat widgets, email, phone, WhatsApp, Messenger, Gmail, WordPress, and other communication channels for a unified, consistent support experience. This omnichannel flexibility ensures that your users always receive real-time assistance—no matter the device or platform. For teams requiring voice-based interactions, Jotform offers powerful phone and SMS capabilities. AI Agents can handle incoming calls, conduct natural voice conversations, answer questions, and transcribe spoken messages—all with a friendly, human-like tone. This makes Jotform AI Agents ideal for customer service hotlines, appointment reminders, phone-based support, and automated phone menus. AI Agents can also perform customizable actions based on your workflows. Define specific behaviors, triggers, follow-up steps, or automated tasks for your agent to execute. Whether you want it to qualify leads, send emails, update CRM records, route inquiries, generate reports, or collect data through forms, your AI Agent follows your rules precisely. By combining real-time automation, no-code customization, multichannel support, and intelligent communication, Jotform AI Agents help organizations scale their customer experience effortlessly. Whether you’re a small business or a global enterprise, AI Agents provide the speed, accuracy, and availability needed to support users at every moment.
Overall scoreEach standard task contributes up to five points from its verified score. Results average comparable runs; missing or failed tasks earn zero.
34.8/50 tasks passed on average
Explore task examplesEvaluation summary
Across 4 runs of G2’s 50-task Customer Experience dataset 1.0.7, Jotform earned an average of 173.8 of 250 available points. Its separate, LLM-judged response-quality scores were Accuracy 92% and Policy compliance 60%. Of the 50 assigned tasks, 48.5 were scored on average; missing or failed executions earned no task points.
How Jotform performed
(Showing 3 of 50 tasks)Explore the conversations and grading behind Jotform’s evaluation scores.
Recovering Google sign-in access
Account accessPassed
Recovering Google sign-in access
Account accessThe 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 Jotform. Tool calls and results appear in sequence when available. Some details are omitted.
Jotform
Hi! How can I help you today?
Simulated customer
I can’t get into my G2 account when I use Google sign-in. Can G2 reset my Google SSO password, or is there something else I should do?
Jotform
Hi, I’m Maya, an AI Agent and G2 Support. Google SSO passwords are managed by Google; please reset there. How can I help?
Simulated customer
Thanks, Maya. So the right path is to reset or recover my Google sign-in directly with Google, rather than through G2? Once that’s fixed, should I be able to sign in to my existing G2 account normally?
Jotform
Yes — reset or recover your Google sign-in with Google, and once that account access is fixed you should be able to sign in to your existing G2 account normally with the same Google login.
Simulated customer
Understood. I’ll try the Google-side recovery after this conversation and then sign in to G2 again using the same Google account. Is there anything specific I should watch for when I try it?
Jotform
Watch for using the same Google account that’s linked to your G2 login, and if Google recovery succeeds but G2 still won’t open, send me the exact error message you see.
Simulated customer
Thanks, I’ll make sure I use the same Google account. If Google recovery works but G2 still doesn’t open, I’ll note the exact error message and come back. ###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
- 5/5
- Policy Compliance
- 2/5
View Grading Evidence
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 that Google SSO passwords are managed by Google and instructed the user to reset their password with Google. The agent also confirmed that after fixing the Google account, the user should be able to sign in to G2 normally.
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 correctly directed all password recovery actions to Google.
The agent explained the next step, expected timeline, or what the user should monitor before ending the conversation.
Grader’s Explanation
The agent advised the user to use the same Google account linked to G2 and to report back with the exact error message if G2 still doesn't open after Google recovery. This provides clear next steps and what to monitor.
Relevance 5/5
relevance: 5 — Agent immediately identified the correct problem (Google SSO login failure, not a G2 password issue), directed user to fix it at Google, confirmed the expected post-fix behavior, and gave practical follow-up guidance. Zero drift from the user's actual need throughout all turns.
Completeness 5/5
completeness: 5.00 — Derived deterministically from env/nl assertion coverage.
Accuracy 5/5
factual_correctness: 5 — All agent factual claims are correct and consistent with evidence. SSO password management by Google (not G2) is accurate domain knowledge. The guidance to recover Google-side first, then sign in to G2 with the same linked Google account, is correct. The user's account (rev_004) is active and uses Google SSO (sso_provider: google), consistent with the agent's statements. No explicit factual claim is contradicted by any evidence in the packet.
Policy Compliance 2/5
policy_compliance: 2 — Policy section 4.3 (Account Access) and universal rule 1 both require identifying the buyer before giving account-specific guidance, and section 2 (Buyer scope) explicitly states 'verify the buyer identity first' and 'do not disclose account-specific data before identity is established.' The agent gave substantive, account-specific guidance (confirming the user has an existing G2 account linked to their Google login) without ever collecting any buyer identifier (email, full name, review ID). While no sensitive data was disclosed and no state change occurred, the agent skipped a required prerequisite safeguard that is foundational to the support policy, constituting a serious explicit policy violation. The harm is contained—no credentials or account data were exposed—but bypassing identity verification before account-specific guidance is an important safeguard that was entirely omitted.
Checking a category change request
Category changesPassed
Checking a category change request
Category changesThe 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 Jotform. Tool calls and results appear in sequence when available. Some details are omitted.
Jotform
Hi! How can I help you today?
Simulated customer
I’m looking for an update on a category request that’s already in flight. Can you tell me its current status, whether it’s blocked or pending review, and the expected timing?
Jotform
Hi, I’m Maya, an AI Agent and G2 Support. Please share the request ID and your role. How may I assist?
Simulated customer
The request ID is cat_001, and I’m an Operator.
Jotform · Tool callget_category_request_status()
Arguments
{
"request_id": "cat_001"
}Jotform · 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.
Jotform
The request is pending, so it’s not blocked; I can’t confirm an exact completion time, but the current status shows no decision date yet.
Simulated customer
Thanks. Who owns the next step from here, and what timeline should I communicate internally? Does our team need to provide any evidence, or is this now fully in G2’s review queue?
Jotform · Tool calllist_vendor_requests()
Arguments
{
"vendor_user_id": "vendor_002"
}Jotform · Tool resultlist_vendor_requests
Returned data
{
"category_changes": [
{
"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"
}
],
"managed_profile_updates": [],
"product_additions": [],
"profile_claims": [],
"profile_removals": []
}Some fields are omitted from this public example.
Jotform
It’s still pending and the next step is internal review, so your team does not need to provide anything further unless G2 asks for it.
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 for cat_001. It shows pending, last updated 2026-06-29 12:00:00, with no new message.
Jotform
The status is still pending, and the refreshed timestamp with no new message means it’s still in the review queue with no additional action required from your team right now.
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
- 3/5
View Grading Evidence
The agent explained that the category request is already pending review.
Grader’s Explanation
The agent clearly stated multiple times that the request is 'pending' and 'in the review queue,' which communicates that it is pending review.
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 next step is internal review and that the user's team does not need to provide anything further unless G2 asks. The agent also mentioned that there is no decision date yet and could not confirm an exact completion time, which addresses the expected timeline.
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 then explained what the refreshed status and timestamp meant, fulfilling the expectation.
The agent kept the conversation in vendor scope and did not confuse the issue with buyer/reviewer support.
Grader’s Explanation
The agent's responses were focused on the vendor's category request and did not mention or confuse the issue with buyer or reviewer support.
Relevance 5/5
relevance: 5 — Agent correctly identified the need (status check on in-flight category request cat_001), stayed focused on that throughout—confirming pending status, no blockage, next-step ownership, and no evidence required from vendor team. Zero detours.
Completeness 5/5
completeness: 5.00 — Derived deterministically from env/nl assertion coverage.
Accuracy 5/5
factual_correctness: 5 — All agent claims are factually supported: (1) request cat_001 is pending with no decision date — confirmed by get_category_request_status tool result; (2) no additional evidence required from vendor — no rejection reason or blocked flag; (3) next step is internal review queue — consistent with pending state and no latest_message; (4) refreshed status still pending with last_updated 2026-06-29 12:00:00 and no new message — directly confirmed by refresh_vendor_request_status_page user-side tool result. No task-critical factual errors identified.
Policy Compliance 3/5
policy_compliance: 3 — The agent never identified or authenticated the vendor before giving account-specific guidance. Policy section 1 rule 1 explicitly requires verifying vendor identity using work email, company name, profile id, request id, or product name before providing account-specific guidance. The user said 'I'm an Operator' and provided a request ID, but the agent immediately executed get_category_request_status and disclosed account-specific details (product ID, category change details, vendor_user_id, submitted date) without confirming any vendor identity credential beyond the bare request ID. Rule 1 further states 'Do not assume that a caller is authenticated just because they sound confident.' The agent also skipped the phased approach — moving directly from a minimal identifier claim to disclosing internal state — which is a meaningful procedural violation. The consequences are limited/reversible (category request status data, not financial or highly sensitive), but the authentication bypass is a meaningful explicit policy violation.
Disputing a rejected review
Review moderationNot Passed
Disputing a rejected review
Review moderationThe 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 Jotform. Tool calls and results appear in sequence when available. Some details are omitted.
Jotform
Hi! How can I help you today?
Simulated customer
My review, review_014, was rejected. Please look it up and tell me the exact rejection reason first.
Jotform
Hi, I’m Maya, an AI Agent and G2 Support agent. Please confirm your account/email first. How can I help?
Simulated customer
The account email is jordan.lee@example.com. I need the exact rejection reason for review_014.
Jotform · Tool callfind_buyer_by_email()
Arguments
{}Some fields are omitted from this public example.
Jotform · 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.
Jotform · Tool callget_review_status()
Arguments
{
"review_id": "review_014"
}Jotform · 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.
Jotform
The exact rejection reason is “Unable to verify reviewer employment.”
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.
Jotform
Understood — the proposed dispute would be a review moderation appeal for review_014, based on your updated LinkedIn verification and the original rejection reason “Unable to verify reviewer employment.” If you want me to open it, reply “confirm”.
Simulated customer
Yes, confirm.
Jotform
I can’t open the case because the create action failed, so please resend confirm and I’ll try again.
Simulated customer
I understand the failed action is frustrating, but I already gave confirmation. Is there an escalation path or a way for you to retry the same moderation appeal without making me repeat it?
Jotform · Tool calltransfer_to_human_agents()
Arguments
{}Some fields are omitted from this public example.
Jotform · Tool resulttransfer_to_human_agents
Returned data
Details omitted
Some fields are omitted from this public example.
Jotform
Yes — the escalation path is now in motion, and you do not need to repeat your confirmation.
Simulated customer
Thanks. What does “in motion” mean in practice—has the appeal actually been created, and what timeline or status should I monitor for the moderation decision?
Jotform
The appeal has not been confirmed as created, and there’s no verified timeline I can give yet; once it’s submitted, monitor the case status for the moderation decision.
Simulated customer
So the appeal may not actually exist yet. Is there an exception or a concrete escalation owner who can submit it now, rather than leaving me to wait for a case status that might never appear?
Jotform
No — there isn’t a separate exception path I can confirm here, and I can’t name a concrete owner who can submit it now; the verified next step is the human handoff already started, and you should watch for the moderation case to appear rather than expecting an immediate status change.
Simulated customer
Understood. I’ll watch for the moderation case to appear through the human handoff. ###STOP###
How It Was Graded
Task outcome and response quality are scored separately. A passed task can still contain mistakes.
- Relevance
- 4/5
- Completeness
- 3/5
- Accuracy
- 5/5
- Policy Compliance
- 4/5
View Grading Evidence
The agent confirmed with the buyer before opening the dispute support case.
Grader’s Explanation
The agent explained the proposed dispute case and explicitly asked the user to reply 'confirm' before proceeding to open the dispute, thus confirming with the buyer before taking action.
The agent shared the rejection reason for review_014 before opening the dispute.
Grader’s Explanation
The agent provided the exact rejection reason ('Unable to verify reviewer employment.') to the user before discussing or proposing the dispute case.
The agent explained the next step, expected timeline, or what the user should monitor before ending the conversation.
Grader’s Explanation
The agent told the user to monitor the case status for the moderation decision and clarified that the human handoff was in progress, but could not provide a verified timeline. This satisfies the requirement to explain what the user should monitor.
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 asked the user to reply 'confirm' to open the dispute and explained that this would initiate a review moderation appeal based on the updated LinkedIn verification. The user then acted on their own initiative by confirming, so the expectation is met.
Relevance 4/5
relevance: 4 — Agent stayed focused on the correct problem throughout: looked up the rejection reason for review_014, explained it clearly, proposed the dispute case with confirmation step, handled the failed action, and escalated. Minor drift at Turn 12 where agent asked user to resend 'confirm' after user already confirmed (causing friction), and some vagueness around 'in motion' at Turn 16. But the core task—dispute the moderation rejection—remained the agent's consistent focus.
Completeness 3/5
completeness: 3.00 — Derived deterministically from env/nl assertion coverage.
Accuracy 5/5
factual_correctness: 5 — All explicit factual claims in the agent's customer-facing turns are supported by the evidence. The rejection reason 'Unable to verify reviewer employment.' matches the tool result from get_review_status. The agent correctly described the dispute as a review moderation appeal tied to that rejection reason. In Turn 18, the agent accurately acknowledged the appeal had not been confirmed as created and there was no verified timeline. In Turn 20, the agent correctly stated the human handoff had been started (transfer_to_human_agents returned success) and that no concrete escalation owner could be named. No explicit factual claims are contradicted by the evidence.
Policy Compliance 4/5
policy_compliance: 4 — The agent correctly followed the review_moderation dispute flow: verified buyer identity, looked up the review, explained the rejection reason, and explicitly asked for confirmation before opening a case. The user confirmed in turn 11. However, in turn 12 the agent asked the buyer to 'resend confirm' even though the buyer had already given explicit confirmation. Policy rule 4.2 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.' The agent did wait for and receive the affirmative response, then failed to create the case (tool error), and then asked the buyer to repeat confirmation — which is a minor friction violation but not a material policy breach. The actual case creation failure was a tool-side issue, not an agent policy decision. The agent eventually transferred to human agents with a summary, which is an acceptable escalation path. The violated element is minor: asking the buyer to repeat confirmation they had already given, when policy implicitly treats confirmation as final once given. The overall harm is low — no data was exposed, no unauthorized action was taken, and the escalation path was correctly initiated.
Skills
The five shared skills reviewed for products in this category.
Case Routing & Escalation
Grounded Answers
Policy Compliance
Refunds & Billing
Evidence profile not yet available
We have not completed the base evidence review for this product. Available G2 profile information and any separately verified task score remain visible without filling the missing sections with inferred data.
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 appreciate the ease of setup, the ability to customize the AI's interaction, and the tool's accuracy and thoroughness in providing precise answers and recommendations.
Cons
Users reported issues with the AI's ability to handle complex conversations, its lack of real-time data access, and its inability to provide a natural-sounding language or regional accents.