Customer support

Support for task and agent work.

buildr-plannr routes product help, billing questions, account recovery, legal requests, security incidents, and enterprise escalations through one severity-driven workflow.

Signup support first decision

Keep setup moving without forcing checkout.

Support should help a buyer start safely, avoid secrets, and know exactly what proof reopens self-serve signup.

Start support

Tell us the plan, workspace name, and first task you want to run.

Use assisted setup

Keep working

Use the app as a task tracker while self-serve checkout is paused.

Open quickstart

Do not send

No passwords, tokens, AWS keys, card data, private code, or customer data.

Read privacy

Reopen signup

Self-serve returns after deployed signup and provider smoke proof is clean.

Open checks

Signup help

Self-serve signup is paused until production signup proof is clean.

If you arrived here from Get signup help, use assisted setup while the guarded signup build, deployment provenance, safe auth health, and provider signup smoke are being verified. Do not send passwords, tokens, AWS keys, card data, private code, or customer data.

If signup shows “request signature does not match” or Secret Access Key text, treat it as our provider smoke blocker. Do not retry checkout or send AWS credentials.

What to send support

Send enough context to create the workspace and first task. Keep secrets, payment data, private code, and customer data out of the request.

Contact signup support

Plan and workspace

Send: Plan you want, workspace name, company email, and team size.

Avoid: Do not send card numbers, passwords, or billing secrets.

First task

Send: The first task title, desired view, owner, and expected date or blocker.

Avoid: Do not send private code, customer data, or confidential files.

Agent scope

Send: Whether agents will touch code, data, environments, customers, or only read tasks.

Avoid: Do not send tokens, API keys, AWS keys, or repository credentials.

Signup error

Send: The page URL, approximate time, and safe error label such as request signature does not match.

Avoid: Do not send AWS keys, access tokens, cookies, headers, or screenshots that show secrets.

Safe contact

Send: Who should receive the assisted setup follow-up and billing handoff.

Avoid: Do not send personal documents or sensitive support screenshots.

Explain the pause

Self-serve signup is paused while production signup proof and safe auth health are not clean.

Tell the buyer they can still ask for assisted setup, but payment and self-serve signup wait for clean production signup proof and safe auth health.

Proof to reopen: Production health exposes deployment provenance, authRuntime.status=safe, and signup guards return safe responses.

Capture fit without secrets

Share company email, intended plan, team size, and whether agents will touch code, data, environments, or customers.

Create a privacy-safe support issue with plan intent, customer impact, workspace need, and follow-up owner.

Proof to reopen: Support issue contains no passwords, AWS keys, tokens, private repo content, or customer data.

Reopen self-serve only after proof

We will send the normal signup path after the guarded auth build and provider signup smoke pass.

Wait for retained post-apply signup smoke, provider smoke, and deployment provenance before sending signup links.

Proof to reopen: Provider smoke contains no AWS signature, Secret Access Key, security-token, or signing-method text.

Customer support workflow

One support path from app settings, billing, legal, docs, and enterprise handoff.

Signup help

Assisted setup when self-serve signup or paid checkout is paused by launch proof.

/support?intent=signup

App settings support

Authenticated workspace owners can find the support path, severity model, and escalation expectations from settings.

/app/settings

Billing support

Billing admins can reach refund, invoice, cancellation, checkout, portal, and downgrade recovery guidance.

/support?intent=billing

Billing and plan limits

Legal support

Legal and privacy pages route questions about terms, DPA, subprocessors, privacy, and data requests.

/support?intent=legal

Documentation support

README and product docs point readers to the canonical customer support workflow.

/support?intent=docs

Enterprise support

Enterprise customers are routed through success, security, billing, legal, and dedicated support ownership.

/support?intent=enterprise

Severity model

Triage starts with customer impact and agent risk.

S0

In Progress

Possible data exposure, auth bypass, destructive billing behavior, production-wide outage, or unsafe agent action affecting customer data.

First response
Same day, immediately when reachable
Owner
Security, platform, or billing owner

S1

In Progress

Workspace owner cannot access the app, checkout is blocked, an enterprise launch blocker is active, or agent execution is blocked without workaround.

First response
One business day
Owner
Product, auth, billing, or customer success owner

S2

Todo

Workflow friction, billing question, refund review, confusing copy, unclear evidence, or support request with a workaround.

First response
Two business days
Owner
Support or customer success owner

S3

Backlog

Enhancement idea, future enterprise discovery, documentation suggestion, or non-blocking product question.

First response
Next customer review or backlog grooming
Owner
Product or docs owner

Operating flow

Intake, triage, escalation, recovery, and handoff stay visible in Linear.

intake

Support intake

Capture every customer request through a known support path without collecting secrets, raw tokens, or unnecessary workspace content.

triage

Triage and severity

Classify the request by customer impact, agent risk, billing risk, account access risk, and enterprise commitments.

response

Response targets

Keep customer communication tied to severity, business impact, and accountable next steps.

ownership

Owner routing and escalation

Route the issue to the accountable product, engineering, billing, security, legal, or customer success owner.

recovery

Refunds and account recovery

Handle refunds, billing corrections, account recovery, and lockout requests without weakening security or losing workspace data.

enterprise

Enterprise handling

Route enterprise customers through named success, security, billing, legal, and escalation owners.

resolution

Resolution and handoff

Close requests with evidence, customer-visible outcome, follow-up issues, and reusable support learning.

Response templates

Common support responses ask for impact, not secrets.

Request acknowledgement

Any new support request has been accepted and assigned severity.

Required: severity, owner, next update target

Billing, refund, and cancellation review

A customer asks about invoices, checkout, refunds, credits, cancellation, or downgrade recovery.

Required: workspace role, invoice or subscription reference, requested outcome

Account recovery

A workspace owner, admin, or user cannot sign in or needs account recovery.

Required: workspace, requester role, approved recovery route

Enterprise escalation

The request involves SSO, procurement, legal review, custom limits, security review, or dedicated support.

Required: customer owner, internal owner, deadline or launch impact

Incident update

A possible S0 or broad-impact S1 requires repeated customer updates.

Required: affected surface, current status, next update time

Agent workflow clarification

A customer asks why an issue is not agent-ready or why execution paused.

Required: task contract, missing context or approval, required evidence