> ## Documentation Index
> Fetch the complete documentation index at: https://docs.buildbetter.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Settings & Billing

> Organization survey settings, sender identity, credit rates for each survey outcome, and how allowances are enforced

## Organization Settings

Survey settings are organization-level and shared across every survey:

* **Sender display name** — shown on invitations, at the verified BuildBetter survey domain.
* **Reply-to address** — where respondent replies go.
* **Company context** — optional context passed to AI follow-up generation, so clarifying questions sound like they came from your team.

<Info>
  The From *domain* is not configurable. Invitations send from the verified `surveys.buildbetter.ai` sender; arbitrary unverified customer domains are deliberately unsupported. See [Audience & Delivery](./audience-and-delivery#sender-identity-and-deliverability).
</Info>

## Feature Flag

AI Surveys requires the organization-level `surveys` feature flag. When it is off:

* Authenticated survey mutations are rejected.
* The survey worker defers pending invitations rather than sending them.
* Public token routes return **Survey not found**, after resolving the token's organization.

## What Costs Credits

One credit is **\$0.001**. Four survey-specific meters bill at distinct points in the lifecycle:

| Outcome                |    Credits | Charged when                                                                      |
| ---------------------- | ---------: | --------------------------------------------------------------------------------- |
| Invitation sent        |      **4** | The email provider accepts a non-preview email and the recipient is marked `sent` |
| Response completed     |      **8** | A non-preview response is marked complete                                         |
| AI follow-up generated |      **1** | A generated follow-up prompt is persisted                                         |
| Signal generated       | **4 each** | Per signal inserted by survey-response extraction                                 |

A completed email survey response that generates two follow-ups and three signals therefore costs roughly 4 + 8 + 2 + 12 = **26 credits (\~\$0.026)**.

Response completion bills on **all** paths — including URL and in-app intercept flows that never sent an email.

### What is never billed

* Preview test emails
* Preview recipients
* Test responses marked with the preview test flag
* Suppressed, no-op, or model-failed follow-up decisions

<Tip>
  Preview and test sends are free by design, so verifying the respondent experience before launch costs nothing. Use them liberally.
</Tip>

## Allowance Enforcement

Credit checks happen **before** work is queued, not after:

* **Recipient upload and API recipient creation** check invitation allowance before queuing email-capable recipients. If a batch exceeds available credits, you get an actionable partial-allowance result rather than a silently over-queued send.
* **Activation** surfaces an estimated maximum credit exposure, derived from queued recipients, expected completion rate, enabled follow-up depth, and average signals per response.
* **The organization advisory lock** that serializes allowance checks counts pending reservations that have not yet reached the usage ledger, so concurrent imports cannot over-reserve.

### Running out mid-flight

Exhausting credits degrades gracefully rather than losing data:

| Point of exhaustion  | Behavior                                                                                                                |
| -------------------- | ----------------------------------------------------------------------------------------------------------------------- |
| Before an invitation | Recipient stays unsent in `billing_blocked`, visible in the recipients table, retried automatically as capacity returns |
| Before a follow-up   | Answer saves, survey continues, no follow-up generated                                                                  |
| Before extraction    | Response stays visible; extraction job stays retryable/blocked with a clear billing reason                              |

## Idempotency

Billing events are idempotent through `(model_id, rule_id)` uniqueness. Replays may update the input value but never double-bill the same model and rule.

This holds in the awkward cases specifically:

* The provider accepts an email but the status update fails — the retry does not create duplicate invitation billing.
* The provider fails before acceptance — no invitation billing occurs, and the recipient stays retryable.
* Concurrent answer submissions share one generated follow-up prompt and one charge.

If a post-hoc billing report is rejected after customer-visible work already committed, the shared billing reconciliation worker retries the charge rather than dropping it or failing the completed survey operation.

## Send Limits

Independent of credits, throttles cap **1,000 invitations per hour** per organization and **500 per hour** per survey. See [Audience & Delivery](./audience-and-delivery#send-limits).

## Next

<CardGroup cols={2}>
  <Card title="AI Surveys Overview" icon="clipboard-question" href="./overview">
    How the whole feature fits together.
  </Card>

  <Card title="Subscription Plans" icon="credit-card" href="../FAQ/subscription-plans">
    Plans and credit allowances.
  </Card>
</CardGroup>