A launch-ready support boundary for DoorFrame data packets: source issues, fulfillment questions, payment sync problems, refund review, and what DoorFrame can safely say.
DoorFrame support should help customers understand packet status without turning public records into unsafe conclusions.
For now, support should be routed through the customer dashboard, Stripe receipt context, and founder/admin review until a branded support inbox and admin support queue are explicitly approved.
Do not publish an unapproved branded inbox until operations owns it.
During launch, DoorFrame should review customer packet and payment-sync support issues within two business days.
There are no automatic refunds from this route; refund requests are reviewed against packet and source state.
Raw API output, raw admin notes, and unsafe AI drafts stay hidden from the customer.
DoorFrame is not legal, safety, compliance, permit, price, insurance, tax, appraisal, or provider-quality authority.
These are the support states customers and admins should see before public launch.
If a selected public source returns no matching rows, DoorFrame should show a reviewed no-match note instead of pretending the source proved anything.
If a public source is old, delayed, or unclear about freshness, DoorFrame should show the checked date, caveat, and review state before the packet is customer-ready.
If two sources disagree, DoorFrame should mark the packet for review, explain the conflict carefully, and avoid turning either source into an authority claim.
If source fetching, review, blocked-claim scanning, or admin approval takes longer than expected, the customer dashboard should show the packet status honestly.
If the wrong address, package, or context was submitted, DoorFrame should route the issue to manual support review before re-running sources or changing delivery state.
If Stripe payment succeeds but the dashboard does not update, DoorFrame should use the receipt and request state to reconcile the order without exposing private payment secrets.
Refund language should be calm, specific, and tied to the paid packet state rather than vague promises.
Refund requests are reviewed manually. There are no automatic refunds, automatic reversals, provider payouts, escrow flows, or marketplace dispute flows in DoorFrame.
Useful refund-review context includes the packet ordered, payment status, submitted address, source states, fulfillment delay, no-match rows, stale source caveats, and whether the customer dashboard displayed reviewed output.
Support cannot declare a property safe, legal, compliant, fairly priced, insurable, appraised correctly, tax-correct, or provider-recommended. DoorFrame support helps interpret the packet workflow, not decide authority claims.
Customers should understand why a paid packet can be paid but not immediately customer-ready.
Support language should reinforce the same contract as the paid packet and customer dashboard.