Provider support · evidence pilot

Your service is up. One customer still cannot connect.

Before a screen-share or engineering escalation, send one trusted command. NetOkay turns the customer’s real CLI or Agent path into redacted, bounded evidence they can review before sharing.

Terms on this page: Evidence is the single JSON EvidenceBundle that a CLI or Agent run writes to stdout: observed facts, explicit unknowns, policy decisions, and redaction notes. Bounded means each check has a fixed scope, time limit, and size limit, and changes nothing on your system.

Request a ticket audit See the pilot scope ↓

Start with ticket counts and a redacted taxonomy. Do not email Evidence, secrets, payloads, or customer data.

TriggerNo request ID
PathHTTPS · SSE · WSS · MCP
HandoffOriginal support ticket

The qualifying incident

Run NetOkay only where server-side evidence stops.

The pilot starts when a paying developer cannot connect, your status and server traces do not explain the failure, and the customer is willing to run a bounded local command.

If a request ID already explains the case, or an existing doctor resolves it, NetOkay should not add another step.

Fixed pilot scope

An evidence pilot, not a SaaS promise.

The first engagement collects evidence about whether the support outcome is valuable, before NetOkay sets a price or builds accounts, storage, dashboards, or billing infrastructure.

Fee: None during the pilot
Window: 30 days
Provider: 1 team
Pattern: 1 standard transport pattern
Cases: 10–20 redacted live support cases
Delivery: Manual, bounded, measured

What the pilot delivers

Enough workflow to test the buying decision.

01Ticket audit
Classify recent connection, TLS, timeout, SSE, WSS, or MCP cases without collecting customer payloads.
02Current Runner
Use the existing v0.3 CLI and Agent Skill from the customer’s chosen execution context.
03Manual handoff
The customer reviews the redacted Bundle and attaches it to the original support ticket.
04Weekly outcome ledger
Track completion, actionable evidence, time-to-evidence, support effort, and inconclusive results.

Evidence handoff

Show the boundary before suggesting the next step.

NetOkay reports what this run observed and what it did not. The Provider keeps the final support decision and records the eventual outcome separately.

Synthetic support handoffnot production data

Synthetic example — not a live result

case: support-012
symptom: "curl works; Agent times out"
observed: local CLI proxy route was executable
not_observed: Agent internal HTTP runtime
boundary: no unique root cause established
next_step: compare the Agent child-process proxy environment

user-reviewedticket-ready

Explicit exclusions

The validation does not pretend the platform already exists.

No Dashboard, Provider Inbox, webhook, or automated upload.
No independent regional probe claim.
No automated domain verification, billing portal, or multi-tenant workspace.
No credentials, response payloads, PCAP, or custom protocol work.
Nothing uploads before the user approves sharing.

Success criteria, agreed before the pilot starts

Continue only if the pilot changes support work.

Completion: ≥60% without live NetOkay help
Actionable: ≥40% non-inconclusive evidence
Provider effort: ≤4 hours during the pilot
Safety: 0 secret or payload incidents

Start with evidence, not a demo

Bring counts and a redacted ticket taxonomy.

The first conversation decides whether the cases qualify. It does not require customer Evidence, credentials, payloads, or a production integration.

Two questions decide whether a pilot makes sense: what share of your support tickets are connection, TLS, timeout, or stream failures, and what do you ask a customer to run today? Pricing follows those numbers, not the other way round.

Request a ticket audit

Contact: flreey@gmail.com