Conversation, answer and verification problems

Support is temporarily unavailable#

Identify the first failing stage in Network: installation detect, bootstrap, conversation message, verification request or Action execution. The fallback message shown to the visitor deliberately does not expose every internal failure. A 402 access failure, a stale-conversation 404 and a service-unavailable response are different evidence even if the visitor sees similar wording. Check Overview and Billing for active access and capacity before attempting more test traffic. If the website is detected and the private Knowledge preview works, that narrows the investigation but does not prove the public request path is healthy. Preserve the safe status and time of the original attempt.

A stored conversation is no longer valid#

A fresh browser profile is a comparison tool, not proof that an old user's issue never existed. Use it to check whether the current installation can create and answer a new conversation. Record the old tab's safe error and timing separately. A retained conversation may be unreadable or unusable after expiry even when its browser identifier remains. Changing storage does not restore expired transcript content or verify the customer's identity. Avoid instructions to edit private session keys or call an invented reset API. If the existing tab cannot recover through the normal interface, support needs the reproduction and lifecycle details to identify the underlying boundary safely.

The answer is incomplete or wrong#

Separate an incorrect business claim from an unsupported requested operation. For a wrong delivery estimate, compare the enabled policy source and its processing date. For an order lookup, check whether a tested and enabled Action with permitted identity and provider connection exists. For a current-page mistake, record the exact public route and whether its content has been captured. A long list of documents does not prove that the relevant one is correct or available to this website. Use one question with a known source and one unknown case, then inspect the result. Replacing the installation token cannot repair incorrect business facts.

Email verification or Action card issues#

Action codes last ten minutes, allow five attempts and require sixty seconds between resends. Verified identity lasts thirty minutes in its conversation; pending proposals last ten minutes. Interrupted running operations become unknown after fifteen minutes.

Check the entered mailbox before requesting another code. Observe the resend wait, use the current challenge and distinguish an expired code from a provider ownership failure after successful verification. If the verified mailbox does not own the requested record, an unavailable result can be correct. A proposal also has its own expiry and tested revision; mailbox verification does not override those. For an unknown write outcome, first inspect its safe run reference, stored status and the connected system's operation record. Do not issue a new write just because the browser timed out: the provider may have applied the change before the response was lost.

An off-topic boundary is intentional#

In Privacy & Anti-fraud, Response selects monitoring or pausing, and After selects two to five deliberate unrelated attempts. Save Anti-fraud policy applies the chosen control.

The protection policy is about deliberate unrelated misuse over the visitor's shared six-hour support window, not simply a disliked word. Review the actual sequence if a legitimate customer is paused. A new tab is not meant to bypass the same visitor-window policy, and rotating website code is not a way to resolve a false positive. The workspace can choose monitoring or pausing through its supported settings. Keep normal business contact information available in Knowledge and on the website for a visitor who needs assistance while the policy is being reviewed. Fixed boundary responses are distinct from ordinary AI answer attempts in the usage rules.

A human handoff is not an instant human reply#

Read the handoff status instead of inferring delivery from conversational prose. A proposed human handoff, a saved request, a delivered email and a staff response are different milestones. If the form is incomplete, the visitor needs to provide both required contact fields and explicit confirmation. If delivery is pending or failed, use the existing request's supported status check and the business fallback rather than submit several duplicate requests. The destination email and response expectation must be correct in the configured escalation settings. An internal delivery record cannot establish that the recipient read the message, so communicate only the milestone the service actually confirms.

Use the public request sequence to narrow the fault#

The usual first-message path has three stages: installation detection, conversation bootstrap and the message request. Detection targets /v1/widget/installations/detect. A new conversation uses /v1/widget/bootstrap; its answer uses /v1/widget/conversations/CONVERSATION_ID/messages. All use the default API origin https://api.reesponder.com. An existing stored conversation can skip fresh bootstrap, so compare its message request with a clean controlled profile rather than expecting identical sequences in every tab. Opening the panel alone is not the same as submitting a first question.

Record the first rejected or blocked request and safe response code. A 403 at the origin boundary calls for the registered hostname/current installation check. A 402 access or capacity refusal calls for the workspace's effective access and paid pool. A 404 on an old conversation calls for its lifecycle and association evidence. A network block or service failure needs a different investigation. These statuses narrow the stage; they do not authorise exposing request tokens in a ticket or repeatedly issuing billable test messages. Preserve the original time and route, then run the smallest controlled comparison needed to establish whether a new public conversation is operational.

Turn an inaccurate answer into a reproducible source test#

Choose one concrete claim from the answer and identify the authoritative business source. For example, if delivery to Germany is described incorrectly, locate the enabled delivery policy for this website and compare its current wording, scope and processing state. Record the question, the expected fact and the source reference using non-sensitive text. Check for conflicting older pages or a shared source belonging to another brand. A large library is not better evidence than the one relevant current source, and changing the public installation token has no bearing on the policy fact.

Use a small set of cases to verify the correction: the original question, a nearby wording and an unsupported scenario. The last case should lead to an appropriate uncertainty or contact path rather than an invented business promise. For a private question, inspect the Action and identity boundary instead of uploading customer records into Knowledge as a shortcut. If the portal's private five-question test succeeds while public support fails, keep that distinction in the report: private preview checks current Knowledge, but does not prove every public context, installation or connected operation. Stop after the controlled cases and record the corrected source ownership so the error is less likely to return.

Give the right owner the smallest useful incident#

Route the incident by its failing boundary. The website publisher handles missing or stale loader output. The billing owner handles effective access, allowance and payment state. The Knowledge owner handles inaccurate business facts. The endpoint owner handles provider permissions, ownership decisions and uncertain external operations. Support staff handle handoff delivery and customer follow-up. In a small company these may be one person, but separating the responsibility prevents a billing fix from being mistaken for repair of a private record-authorisation failure.

Prepare a safe incident record with final public route, browser, time, request stage, expected result and relevant non-secret reference. For an unknown write, preserve its existing run and provider operation evidence before any replacement submission. For a handoff, distinguish saved, delivered and replied rather than treating the conversation's wording as proof of email arrival. For a protection boundary, review the legitimate question and sequence without immediately disabling every safeguard. After the specific repair, repeat the original case and its relevant failure boundary. Record the observed outcome once, so the team can explain what changed and what remains outside the verified scope.

Compare a refused lookup and an uncertain write#

Consider an order lookup that verifies the mailbox successfully but returns no permitted record. First confirm the order reference and the customer relationship in the connected provider. The problem may be a legitimate ownership refusal, missing provider permission or a disconnected source, rather than failed email verification. Now compare a request that changes a delivery address and returns unknown after a timeout. That case needs reconciliation of the existing operation before a new submission. Retrying both cases with the same generic advice would either expose private data or risk a duplicate change. Keep the stage, identity proof and operation outcome separate.

Verify the outcome and keep safe evidence#

After recovery, repeat the original case using synthetic or authorised minimal data, then test the relevant failure boundary too. For identity, verify an authorised owner and an unrelated mailbox. For Knowledge, compare the real policy and an unsupported question. For handoff, verify submitted and delivered states separately. For a write, confirm the operation exists once in the connected system and that its customer result agrees with the run record. Preserve safe references and timestamps for support; do not export credentials or another customer's records. A friendly fallback is useful, but successful resolution requires the underlying request and authorisation path to behave correctly.