> ## Documentation Index
> Fetch the complete documentation index at: https://docs.tied.com/llms.txt
> Use this file to discover all available pages before exploring further.
# What counts as a resolution
> The complete billability test: four signal tiers, every corroborator, ten never-billable conditions, the void windows, and what is on the receipt.
A resolution bills only when a **positive signal** indicates the customer's problem is gone. The absence of a signal is not a signal.
Two rules govern the whole page:
**Silence never bills.** A conversation ending is not evidence that anything was resolved.
Closing a conversation is not evidence. A customer not replying is not evidence.
**Ambiguity resolves to unbilled.** An unclear signal does not bill. This includes borderline
sentiment, uncertain supporting evidence or a partial system state.
For knowledge resolutions, the confirmation rules follow this order:
1. The customer says yes.
2. A teammate marked it resolved and the customer did not come back. This is the weakest corroborated tier, recorded as `human_marked_resolved`.
3. Quiet days, only if you switched them on and there is separate evidence that the answer worked.
The teammate rule is accepted as confirmation evidence, but its automatic waiting check is not yet connected. Quiet days are off by default. Enabling them alone does not enable billing while the outcome evaluator is in observation mode. Silence alone never bills.
A confirmation must arrive within your account's confirmation window. The default is **7 days from the resolution**, and the window is configurable per account. A later confirmation is refused and does not bill.
If a confirmed resolution cannot be billed because the account has no credits, it is held pending. It can be billed once credits are available. If the confirmation window ends first, it closes without charge.
The three confirmation types below describe the evidence a resolution can carry. Tier 0 lists the reasons it cannot bill.
***
## Tier 1: Explicit confirmation
The customer stated the outcome.
| Signal | Detail |
| - | - |
| **The customer says so** | In their own words: *"that fixed it"*, *"perfect, thanks"*, *"all set now"* |
| **A confirmation control is tapped** | A quick reply, a list-picker choice, or a form submission whose purpose is confirming the outcome |
Recorded as `explicit_confirmation`.
A positive CSAT rating does not currently create confirmation. A survey response on the conversation prevents a new confirmation from being recorded, even when the rating is positive. See [CSAT](/inbox/csat).
A teammate marking a conversation resolved is not the customer's explicit confirmation. When the customer does not return, that evidence belongs to corroborated silence below.
***
## Tier 2: System-verified outcome
The customer was not asked. A connected system shows the problem is gone.
| Example | What specifically counts |
| - | - |
| **Account unlock** | The account was unlocked **and the customer then logged in successfully**. The unlock alone is not the signal; the successful login is |
| **Refund** | The refund **settled** at the processor, with no chargeback inside the window |
| **Reshipment** | The **carrier shows delivery** |
| **Booking** | The **appointment exists** on the calendar the customer was booking into |
| **Payment** | The **payment completed** at the processor |
Every one of these is a state change **in your systems**, not in Tied's. It requires the agent to hold read scope on the system that proves it, which is why this tier is reachable only where an integration is connected.
Recorded as `system_verified`.
***
## Tier 3: Corroborated silence
The customer said nothing further. Billable **only** when all three conditions hold. Not two.
A specific, on-topic response to the question that was actually asked.
Not later in the thread, and not on the resolution afterwards.
One of the five below. The set is closed.
| Corroborator | What it is |
| - | - |
| **Message read** | A channel-level read receipt. Only on channels that emit one |
| **Link opened** | A link sent in the resolution was opened |
| **System state changed consistently with resolution** | The tracked shipment moved, the session authenticated, the draft order converted |
| **Next contact is unrelated** | The customer came back, and came back about a different issue entirely |
| **A teammate marked it resolved** | A teammate marked it resolved and the customer did not come back. Recorded as `human_marked_resolved` |
Silence plus a corroborator is evidence. Silence on its own is not, and does not bill.
Recorded as `corroborated_silence`.
This is the weakest confirmation tier. A teammate mark alone is insufficient. The customer must not have returned. The automatic waiting check is not yet connected. Quiet-day confirmation also requires your account to have switched it on.
***
## Tier 0: Never billable
These are the ten reason codes for an unbillable record. Confirmation refusals and credit holds are tracked separately.
| Reason code | Condition |
| - | - |
| `insufficient_evidence` | Silence with no corroborator. **The most common unbilled outcome** |
| `assisted_routing` | The agent routed to a human rather than resolving. Free at every tier |
| `human_took_over` | A human agent sent a message in the conversation before the resolution was confirmed |
| `abandoned_mid_flow` | The customer stopped replying partway through |
| `negative_csat` | A negative outcome prevents billing. See the CSAT policy and void rules below |
| `agent_couldnt_help` | The agent stated it could not help |
| `greeting_only` | A greeting exchange with no substantive answer |
| `misuse` | The agent was used as a general-purpose assistant rather than for support |
| `test_sandbox` | Sandbox, evaluation or playground traffic |
| `reopened_within_window` | The same issue reopened within 30 days of its first resolution; any earlier charge is voided |
There is one canonical spelling, `reopened_within_window`, and it is used both for the unbillable reason and for the stored void reason on the billing event. Records written before this was unified carry the legacy void reason `reopen_within_window`; they are still read and treated identically, and are not rewritten. The analytics label for either spelling is `reopen_30d`.
**Test traffic is tracked separately from the reason.** A sandbox conversation that also abandons
partway records `abandoned_mid_flow` **and** carries a test flag: two independent facts rather
than one collapsed into the other. Your QA runs, your red-teaming and Tied's own evaluations never
bill under any circumstances.
### On misuse
If a customer discovers your AI agent will write a cover letter or explain an unrelated topic, that is not a resolution and it does not bill. Off-topic misuse is detected and refused by the [guardrail layer](/agents/guardrails) as well as excluded from billing.
***
## Assisted routing is free
**If the agent engages but cannot finish and hands off to a human, the charge is zero.** Not a
reduced charge, not a routing fee, not partial credit.
The agent typically does real work before handing off: reading the account, gathering context, identifying the issue, and leaving a summary for the human. None of it is billed.
A handoff records **two** things: a `routed_to_human` event carrying which of the seven escalation grounds fired, and an unbillable resolution with reason `assisted_routing` or `human_took_over`. The grounds are:
| Ground | Fires when |
| - | - |
| Human requested | The customer asked for a person. Cannot be disabled |
| Provider unavailable | No model provider was reachable |
| Budget exhausted | The conversation hit its turn or cost ceiling |
| No knowledge | Retrieval returned nothing usable |
| Must refuse | The question fell into a refusal category |
| Not grounded | What retrieval returned did not answer the question |
| Low confidence | The draft was not confident enough to send |
Full detail: [Guardrails and safety](/agents/guardrails).
Note the consequence of `human_took_over`: if a person messages the customer before the resolution is confirmed, the resolution is not billable **at all**, however much the agent did first. Confirmation does not override the credit check or confirmation window. A reopen or a negative survey can still cancel a settled charge.
Confirmation is the dividing line. Once a resolution is confirmed, its fee is **locked**: a person who messages the customer afterwards, or takes over the conversation afterwards, does not cancel it. Only the two void triggers below can reverse a confirmed resolution.
***
## Void windows
A billed resolution is not final when it is billed. Two triggers void it.
| Trigger | Window | Effect |
| - | - | - |
| **The same issue reopens** | **30 days from the issue's first resolution** | The resolution is voided and credited |
| **Negative CSAT** | **Retroactive, no time limit** | When negative-CSAT voiding is enabled and the account has not opted out, the resolution charge is voided. An already-sent charge receives a linked credit |
The default negative CSAT threshold is 1 or 2 out of 5. An account policy can set a different threshold. The survey must rate that resolution. Repeat submissions do not create extra credits. Raising the rating later does not restore the charge.
Voided resolutions do not count in settled totals. The original receipt stays unchanged; the void and any credit explain the adjustment.
**Credits post automatically.** Nothing is filed, no ticket is opened, no case is argued. The
void triggers and the credit is created within 24 hours. It is netted against the next invoice and
shown as its own line, with the reason attached, in the in-app view. See
[The money-back guarantee](/pricing/guarantee).
### How a reopen is matched to the original
Each resolution carries a stable **issue key** and a **per-conversation ordinal**. A later contact about the same issue matches on the issue key, which is what allows a reopen to void the specific earlier resolution rather than an approximate one.
That also means a customer returning about a *different* issue does not void anything. An unrelated next contact can support a Tier 3 confirmation.
***
## How a resolution is recorded
Resolution evidence, confirmation and billing status are kept separately. The original resolution facts stay unchanged when confirmation or billing status changes.
When the agent resolves a conversation, its original facts include the conversation reference,
timestamps, action-trail references, model usage and confirmation status **pending**. Those
facts stay unchanged. Confirmation and a credit hold are recorded separately.
The positive signal is a **separate** immutable record naming which of the three signal types
fired. Absence of this record means the resolution is unbilled. This is why absence-of-evidence
is the default state rather than something that has to be computed.
A teammate-marked resolution with no customer return uses `corroborated_silence` and the
`human_marked_resolved` corroborator, preserving the same three signal types.
Carrying one of the ten reason codes above. A resolution awaiting confirmation or credits stays
unbilled. A confirmation arriving after the window is refused. A pending credit hold closes
without charge when its window expires.
A timer alone never makes a resolution billable. Without an accepted confirmation it does not
bill. An expired confirmation window cannot be revived by a late confirmation or a later top-up.
***
## Every resolution produces a receipt
The receipt is the enforcement mechanism for everything above.
| The receipt shows | Specifically |
| - | - |
| **Transcript reference** | The exact conversation the charge came from |
| **Signal tier and the specific corroborator** | The specific evidence: *which* link was opened, *which* system state changed, *which* login succeeded |
| **Class and its discriminator** | The class assigned, and the specific audit-trail entry that triggered it |
| **Orchestration fee** | The fee for the class assigned |
| **Model cost** | Per call: provider, model, token counts, rate, total |
| **Dispute** | One click |
For `human_marked_resolved`, the explanation says: "A teammate marked it resolved and the customer did not come back. This is the weakest confirmation tier." It does not claim the customer said yes.
## What is reported
Settled resolution totals exclude voided charges and resolutions held pending for credits. Resolutions closed without charge after their confirmation window ends are also unbilled. These outcomes explain why a confirmation may have no standing invoice charge.
## Next
Once a resolution counts, what it costs: the seven classes and their discriminators.
The whole mechanism, including what happens at a zero balance.
The seven escalation grounds behind a handoff.
How voided resolutions post back to your balance.
This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.