Jotform

4.5(792 G2 reviews)

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 score

140points

28/46 tasks passed

Explore task examples

G2 task evaluation

Accuracy82

Policy compliance56

G2 buyer reviews

Ease of use88

Quality of support87

How Jotform performed

(Showing 3 of 46 tasks)

Explore the conversations and grading behind Jotform’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 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 log in to my G2 account using Google sign-in. Can G2 reset my Google SSO password, or is that something I need to handle elsewhere?

Jotform

Hello! I’m Maya, an AI Agent. You need to reset your Google password directly through Google. How may I assist you further?

Simulated customer

Thanks, Maya. Just to confirm, once I reset or recover my Google password with Google, should I be able to use Google sign-in on G2 again right away, or is there anything else I should watch for?

Jotform

Usually yes—once you reset or recover your Google password, Google sign-in should work again right away, and if it still fails the next thing to check is that you’re signing in with the same Google account/email you used on G2.

Simulated customer

Got it—I'll recover it through Google and make sure I use the same account. If Google sign-in still fails afterward, what should I do next?

Jotform

I don’t have that information; if it still fails after you recover Google access, the next step is to contact G2 support with the email on the account.

Simulated customer

Thank you. I’ll try the Google recovery process first, then contact G2 support with my account email if it still doesn’t work. ###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: 2/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 that the user needs to reset their Google password directly through Google, indicating that G2 cannot reset a Google SSO password. The agent also implied that after fixing the Google sign-in, the user should try again.

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 directed the user to Google for password recovery.

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 after resetting the Google password, the user should ensure they are using the same Google account/email. If sign-in still fails, the agent advised contacting G2 support with the account email. This covers the next steps and what to monitor.

Accuracy

factual_correctness: 4 — Agent's key factual claims: (1) reset Google password through Google — correct, G2 cannot reset an SSO provider password; (2) after Google password reset, SSO should work again right away — generally reasonable guidance, though the snapshot shows `sso_working: false` which is current state, not post-recovery state; (3) check same Google account/email — sound advice; (4) if still fails, contact G2 support with account email — appropriate. No claim is directly contradicted by evidence. The one mild issue: the snapshot shows `sso_working: false` but the agent's 'should work right away' framing is presented as typical expectation ('usually yes'), not a certain promise, and is consistent with standard SSO troubleshooting guidance. No task-critical factual error is proven by the evidence.

Policy Compliance

policy_compliance: 2 — The agent violated two explicit policy rules. First, Section 1 Rule 1 requires identifying the caller before giving account-specific guidance, and the agent skipped identity verification entirely, jumping straight to guidance. Second, and more importantly, Section 4.3 (Account Access) Rule 1 states the agent must follow the flow: identify the buyer, determine the failure mode, guide the narrowest correct recovery path, wait for the user to report the outcome, and only then escalate if blocked. The agent skipped identity verification completely and in Turn 7 deflected with 'I don't have that information' rather than following the prescribed flow (e.g., checking same-email alignment, verifying account state with tools, or explaining the escalation path properly). While the core SSO advice (reset password with Google, not G2) was correct per Section 4.3's explicit rule ('for Google or LinkedIn SSO, explicitly state that G2 cannot reset the identity-provider password'), the agent never identified the buyer, never inspected account state, and failed to provide the structured follow-up path required by policy. These are serious violations of the phased approach and identity-first rules, though the consequences are contained since the guidance given was directionally correct and no harmful state change occurred.

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 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 we already have in flight. Can you tell me its current status, whether it’s blocked or awaiting evidence/review, and the expected timing?

Jotform

Hello! I'm Maya, an AI Agent here to assist you. Could you please provide your account identifier? How can I help you?

Simulated customer

The account email is noah.ellis@supportloop.io. The request concerns a category update already in progress—could you check its status and expected timeline?

Jotform · Tool callfind_vendor_user_by_email()

Arguments

{}

Some fields are omitted from this public example.

Jotform · Tool resultfind_vendor_user_by_email

Returned data

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

Some fields are omitted from this public example.

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 · 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 category request is pending for Support Loop / Noah Ellis: it was submitted on 2026-06-29, is currently awaiting review, and there’s no decision date yet.

Simulated customer

Thanks. Who owns the next step from here—your review team or someone on our side—and what timeline can I communicate internally? Also, what qualifies a category request for approval, what evidence is most useful, and what happens if it’s rejected versus simply remaining pending?

Jotform

The next step is on our review side, and you can tell your team it’s still pending review with no decision date yet; I can’t verify a guaranteed timeline beyond that, but the closest confirmed pattern is that these requests are reviewed after submission and may remain pending until evidence is assessed.

Simulated customer

Could you clarify what evidence the review team assesses and the approval criteria? If the request is rejected, is there an edit/dispute or resubmission path, and is there anything our team should do now while it remains pending?

Jotform

For a category change, the review team checks whether the requested category matches the product’s primary use case and whether the submitted evidence supports that match; if it’s rejected, the request is not automatically edited or disputed in place, so the usual path is to submit a new request with stronger evidence, and while it remains pending your team generally doesn’t need to do anything unless you have additional proof to add.

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 page. It still shows pending, last updated 2026-06-29, with no new message.

For internal tracking, should we treat this as review-owned with no action required from our side unless we obtain additional supporting evidence? Is there a typical review SLA or status-change trigger we should monitor?

Jotform

Yes — treat it as review-owned and no action is needed from your side unless you have additional supporting evidence to add; the only confirmed state is pending, and there’s no published SLA or trigger I can verify here, so the safest internal message is that it remains under review until a decision is posted.

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 request is 'pending', 'awaiting review', and that there is 'no decision date yet.' This directly addresses the status of the request as being under review.

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 next step is on the review team's side, that there is no guaranteed timeline or published SLA, and advised the user to treat the request as review-owned with no action required unless additional evidence is available. The agent also clarified that the only confirmed state is 'pending' and to monitor for a decision.

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 page on their own initiative; the agent did not prompt or instruct the user to perform any tool-side action. Therefore, this expectation is met by default.

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 on the vendor's category 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 agent factual claims are directly supported by the tool results. Agent correctly stated: request status is pending (confirmed by get_category_request_status and list_vendor_requests), submitted date 2026-06-29 (confirmed), no decision date yet (decision_date: null confirmed), next step is on the review team side (consistent with domain facts about category changes requiring internal team), no published SLA verifiable (agent did not fabricate a timeline), and treat as review-owned with no action needed from vendor side. The agent did not claim any facts contradicted by evidence. The one area of potential concern — describing review criteria and rejection/resubmission paths — is presented as general process guidance rather than specific confirmed system state, which is appropriate given no tool results cover those specifics. No task-critical factual errors found.

Policy Compliance

policy_compliance: 5 — The agent followed all explicit policy rules throughout the conversation. It identified the vendor caller by work email before providing account-specific guidance (rule 1), moved through phases appropriately (clarify → inspect with tools → explain state → propose next step), did not fabricate internal state or SLA values it couldn't confirm (explicitly stated no published SLA), did not jump to escalation when explanation was sufficient, kept vendor scope correctly, and closed with a concrete next step (treat as review-owned, no action required unless additional evidence available). The category-change flow from section 5.3 was followed: status was checked, self-serve vs. blocked distinction was addressed, and escalation was not opened since the request was simply pending review. No policy rules were violated.

Disputing a rejected review

Review moderation

Not 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 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.

Jotform

I’m Maya, an AI Agent. I need your account details to assist you. How can I help you?

Simulated customer

I’m trying to dispute a rejected review. What account detail do you need to look up the exact rejection reason?

Jotform

I need the buyer’s email or full name to look up the review and exact rejection reason.

Simulated customer

The email on the account is jordan.lee@example.com.

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 for review_014 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

Proposed dispute case: review_moderation for review_014, asking moderation to re-check the rejection because your LinkedIn is now verified; if you want me to open it, reply “confirm”.

Simulated customer

confirm

Jotform

I can’t open the case from here right now, but the proposed dispute is review_moderation for review_014 based on your updated LinkedIn verification; if you want, I can help you draft the exact case text to submit.

Simulated customer

I confirmed because I want that dispute case opened, not just drafted. Is the case definitely not being created from this chat? Is there any escalation or exception so moderation can re-check it now?

Jotform · Tool callescalate_review_to_moderation()

Arguments

{
  "review_id": "review_014"
}

Jotform · Tool result · Errorescalate_review_to_moderation

Returned data

Details omitted

Some fields are omitted from this public example.

Jotform

No — this chat did not create the case, and there is no escalation path for a rejected review here because review_014 is rejected and cannot be escalated to moderation.

Simulated customer

That’s frustrating, especially since the verification issue is now resolved. Is there truly no exception or next step at all—such as submitting a new review—and what should I monitor to know whether I can proceed?

Jotform

I don’t have a verified exception or resubmission rule for this case, so I can’t confirm whether you can submit a new review or what to monitor; the safest next step is to wait until the review flow itself shows a new submit/review option or status change, then try again.

Simulated customer

Understood. Since the original cannot be escalated and no resubmission rule is confirmed, I’ll watch the review flow for a new submit or status option. Is there any typical timeframe for that to appear, or is it entirely dependent on the system?

Jotform

It’s entirely system-dependent here, and I don’t have a verified timeframe to give you; the practical check is whether the review flow shows a new submit or status option, and if it does not, there’s nothing confirmed to wait for yet.

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: 4/5
Policy Compliance: 2/5

View Grading Evidence

CriterionMet

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

Grader’s Explanation

The agent proposed the dispute case and explicitly asked the user to reply 'confirm' if they wanted the case opened, thus confirming with the buyer before proceeding.

CriterionMet

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.') for review_014 before discussing or proposing the dispute case.

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 there is no escalation or resubmission rule confirmed, and advised the user to monitor the review flow for a new submit or status option. The agent also clarified that there is no verified timeframe and that it is system-dependent.

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 did not ask the user to perform a tool-side action; the user acted on their own initiative by providing confirmation. The agent's instructions and responses were clear about what would happen if the user confirmed, so this expectation is met.

Accuracy

factual_correctness: 4 — The agent's key factual claims are well-supported by evidence. Turn 7: rejection reason 'Unable to verify reviewer employment.' matches tool result exactly. Turn 13: 'review_014 is rejected and cannot be escalated to moderation' is directly confirmed by the escalate_review_to_moderation error result. The claim that 'this chat did not create the case' is accurate — no case-creation tool succeeded. Turn 11's claim that it 'can't open the case from here right now' is slightly inconsistent with the prior confirmation flow (the agent attempted escalation and got an error, not a permission issue), but this is a framing/workflow issue rather than a clear factual error about the review state. No task-critical factual claim is directly contradicted by evidence.

Policy Compliance

policy_compliance: 2 — The policy (section 4.2) explicitly 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 correctly followed the pre-confirmation steps and received an affirmative 'confirm' in Turn 10. At that point, the agent was authorized to call `create_support_case`. Instead, the agent declined to open the case (Turn 11: 'I can't open the case from here right now') and then attempted `escalate_review_to_moderation` (Turn 16 tool evidence) — a different tool entirely, which returned an error. The agent never called `create_support_case` despite having explicit user confirmation. This means a legitimately authorized, policy-mandated action was refused, and the user was incorrectly told no escalation path existed. Additionally, the agent disclosed the rejection reason in Turn 7 before completing buyer identity verification — the tool call to `find_buyer_by_email` occurs at turn_ref 6 but the result is used at Turn 7, which is acceptable sequence-wise; however, the agent also disclosed review details before confirming identity in Turn 7 (lookup happened simultaneously with the response). The primary and more serious violation is refusing to open `create_support_case` after explicit confirmation and instead attempting an incorrect escalation path, then telling the user there was no recourse. This is a serious explicit policy violation that left the user without a remedy they were entitled to, though the harm is recoverable (user can contact support again).

Skills

The five shared skills reviewed for products in this category.

Support not documented

Multilingual Support

Support not documented

Case Routing & Escalation

Support not documented

Grounded Answers

Support not documented

Policy Compliance

Support not documented

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 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.