SnapWeb Support overview

SnapWeb Support

Version 0.10.1 lets the ticket owner respond directly to an automated documentation match. Solved my problem resolves the request; I still need help returns an active request to the staff queue, or reopens a resolved request. The response is idempotent, owner-only, recorded on the automated message, and never closes or reopens another customer's ticket.

Version 0.10.0 integrates with SnapWeb Docs without AI or an external service. As a customer describes a request, Support can show up to four matching guides before submission. A strong title, heading, or exact error-code match is also added to the newly opened conversation as a clearly labelled automated resource message. The ticket always remains open for staff review, weak matches never become automatic replies, and Support continues normally when SnapWeb Docs is absent.

Version 0.9.0 keeps email infrastructure customer-operated: administrators connect an inbound-capable provider or deploy the packaged Amazon SES relay in their own account. The settings screen provides site-specific DNS, webhook, and Lambda environment values ready to copy; SnapWeb does not operate or charge for a mandatory email gateway.

Version 0.8.9 switches from the request queue to a focused conversation screen when a ticket opens. The Back control restores the queue and keyboard focus without drawing a browser-default box around non-interactive headings. Staff fields use plain-language Ticket details, Assigned to, Response due, and Save changes labels, with the save action on its own responsive row instead of competing with the due-date field.

Version 0.8.7 adds a no-provider AI safety certification and strengthens the shared UI with ticket-specific conversation control names, complete keyboard focus rings for queue and triage fields, labeled conversation regions, and explicit loading and error states.

Version 0.8.4 exposes Support's own staff-reviewed AI through the SnapWeb MCP tools snapweb.support.prepare_reply_draft and snapweb.support.analyze_request. These tools use the same permission checks, minimization, redaction, rate limits, provider isolation, and audit metadata as the Support workspace. They never send a reply, apply a suggestion, or change ticket state.

Version 0.8.3 adds a launch-readiness table for ShopiChain commerce, outbound notifications, email replies, Support AI, and SnapWeb MCP. Incomplete email or compatible-AI settings now fail closed instead of displaying an enabled state that cannot work. Successful outbound, inbound, and AI certifications are recorded only as outcome and UTC time; secrets, recipients, prompts, and message bodies are never stored in readiness data.

Version 0.8.1 presents authoritative product names instead of internal product identifiers throughout customer and staff request cards. One-time orders, lifetime purchases, and subscriptions retain distinct, accurate labels in both the purchase selector and conversation summary.

SnapWeb Support provides public product questions and private customer support from the /support/ route. Signed-in customers can create and track requests, open a complete conversation, send replies, resolve a request, and reopen it when more help is needed. Private product support checks the customer's authoritative ShopiChain purchase, subscription, or licensing entitlement; public, pre-sales, and general account questions remain available without a purchase.

Version 0.8.0 merges ShopiChain Core purchases and subscriptions with ShopiChain Licensing entitlements in one purchase-aware selector. Recurring products appear once as subscriptions instead of being duplicated by their originating order. Support signs each provider type, public record reference, and product identity into an opaque selection token, resolves ownership and eligibility again during ticket creation, and stores only the normalized support context. Future commerce adapters can contribute through Core's versioned provider-neutral contract.

Version 0.7.0 replaces manual Product ID entry with a purchase-aware selector. The form loads the signed-in customer's ShopiChain purchases and subscriptions, clearly marks expired or otherwise ineligible access, and lets the customer link an eligible item to a private ticket. The browser submits only an opaque selection token. Support resolves it again against the current user's licensing records and stores the authoritative product, public entitlement reference, term type, lifecycle state, and access date. Customers never handle product IDs, order references, license keys, or payment data.

Version 0.7.1 keeps SLA timestamps explicitly UTC from storage through REST, MCP, the staff editor, and repeated triage saves. Changing or resaving another operational field cannot apply the browser or WordPress timezone a second time.

Version 0.7.2 keeps the purchase selector, visibility choice, and submit label synchronized after every successful public or private submission, including while entitlement context is loading or unavailable.

Signed-in customers see public questions together with requests they own; another customer's private request is never included.

The same server-first surface works standalone, inside the SnapWeb persistent shell, and as a native FluentCommunity application route. It inherits each host's light/dark design tokens while retaining accessible focus, loading, empty, error, reduced-motion, and mobile states. Navigation enhancements do not replace server authorization.

Inside FluentCommunity, Support registers a provider-owned application mount and loads the same permission-filtered request contract instead of falling back to a generic post archive.

The dedicated staff operations workspace runs on the same server-rendered standalone, SnapWeb, and FluentCommunity surfaces. Staff can search and filter the queue, set ownership, priority, category, and SLA due time, and see overdue work before opening the complete conversation. Purchase-linked tickets show a safe commerce summary in the conversation and WordPress workflow panel. Existing tickets receive safe normal-priority, general-category, unassigned, and 72-hour SLA defaults when first loaded. Server-side message ceilings and hourly request/reply limits protect every presentation surface from authenticated flooding.

The conversation remains keyboard-accessible and includes the original message, oldest-first replies, live status/list refresh, explicit loading and failure states, and customer-safe lifecycle controls. Reply persistence fails closed if WordPress cannot store the message. Customers can resolve or reopen requests they own, and signed-out visitors can load public questions without an empty REST nonce. Support can prepare staff-reviewed reply drafts and structured ticket analysis through its own configured OpenAI-compatible provider without requiring Cointacted AI or another AI plugin.

When an inbound mailbox relay is configured, customer notifications receive a ticket-specific Reply-To address. A customer can reply from their normal email client and the verified message is added to the existing ticket conversation. The email provider remains replaceable: Support owns ticket tokens, authorization, replay protection, workflow changes, and storage.