> For the complete documentation index, see [llms.txt](https://docs.peakcommerce.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.peakcommerce.com/product/journeys-and-pages/journey-steps/concessions.md). # Concessions A **concession** is a governed, time-boxed discount a staff member can apply from the order summary while they're working a change-plan journey with a customer — a retention save, a service-issue credit, a billing-error correction. Concessions are configured per journey step, not in a global settings area, so the audience that already sees the journey is the audience that gets the capability. The whole model rests on one idea: **a concession is not a free-form percentage.** Staff pick a value, and that value resolves through a **band** to a specific rate plan in your billing catalog — the *instrument*. That resolution is what makes the discount land in the right GL bucket, which is what finance actually cares about. ## Bands, instruments, and GL routing A **band** covers a range (`0–10%`) or a fixed menu of exact values (`25% only`), and is pinned to exactly one **instrument** — a synced discount rate plan from your billing system. It also carries a display-only **GL label** so staff and auditors can see where the discount posts. When a CSR applies, say, 5%: 1. The value `5` is matched against the tenant's bands. 2. The matching band's **pinned instrument** is the rate plan added to the subscription. 3. The `5` is sent as a charge override on that rate plan. So the **value** comes from the band, and the **accounting treatment** comes from the pinned instrument. Two bands can both grant 5% and post to completely different GL buckets — that separation is the point. Bands are **tenant-level and shared**. Any journey can attach an existing band; editing a band changes it for every journey that offers it, which is deliberate — the same discount should always post to the same place. To diverge, create a separate band. ## Resolution is fail-closed Concessions refuse rather than guess. A value is rejected, with the reason stated, when: * **No band covers it** — nothing to resolve through, so there is no defined GL treatment. * **Two bands overlap it** — ambiguous routing; the editor also blocks overlapping bands on save. * **The band has no pinned instrument, or its pin has drifted** — the catalog plan it pointed at was removed or re-synced. The band reports as *drift* and is un-offerable. * **The value exceeds the journey's ceiling.** A band that can't resolve is shown as un-offerable in the editor rather than silently falling back to some other rate plan. A silently substituted instrument would be a discount posting to the wrong GL bucket without anyone noticing. *** ## ⚠️ Gotcha: how seeded bands choose their instrument New tenants are seeded with two starter bands (a generic band and a retention band). **Their instrument pin is picked automatically, and the plan it picks is essentially arbitrary. Always re-pin seeded bands before you rely on them.** Here is exactly what the seeder does, because the behavior surprises people: * It scans the tenant's synced billing rate plans and takes the **first one** it finds whose charge model is a percentage discount, then stops looking. * **It is not round-robin, and it is not "closest match."** There is no ordering applied to the scan, so "first" means whatever the database happened to return first — not the oldest, not the cheapest, not the one whose percentage matches the band. It can just as easily land on an archived or oddly-named plan such as *"Audience Insights Expired 20.06.2026."* * **Every seeded band gets the same instrument.** Both starter bands are pinned to that single plan — they are not distributed across your discount plans. * **A band's own percentage range has no relationship to the plan it's pinned to.** A `0–10%` band can be pinned to a plan named *"25% Discount."* The customer is still charged the value the band sends, so nothing looks wrong on the invoice — but the discount **posts against the pinned plan's accounting codes.** This is the failure worth catching: it is financially wrong and visually invisible. * If no percentage-discount plan has synced yet, bands are created **unpinned** and reported as drift. That's intentional — an un-offerable band is honest; a wrongly-pinned one is not. **What to do:** open **Concessions → Edit** on each seeded band and use **Change** next to *Pinned instrument* to select the rate plan finance actually intends for that band, then set the **GL label** to match. Do this before enabling concessions on a journey. **Re-pinning is safe and permanent.** The seeder only ever fills in a pin that is empty — it will never overwrite a pin you set deliberately, on this or any later deploy. ## Configure concessions on a step 1. Open the journey builder: **Content → Journeys → Edit → Steps**. 2. Edit the step that renders the order summary, then open the **Concessions** tab. The tab is admin-only and always visible to admins. 3. Turn on **Show concession in order summary**. This toggle alone governs whether staff see the composer in the rendered order summary — there is no separate permission to grant. 4. Attach the bands this journey may offer, set the **ceiling**, and choose the **reasons** and **durations** staff can pick from. Reasons and durations are editable lists — use **+ Add reason** / **+ Add duration** to extend them, and **Allow custom duration** to let staff enter an arbitrary number of billing periods. ### Evergreen (no end date) Turn on **Allow evergreen (no end date)** to add an **Evergreen** option to the duration picker. An evergreen concession has no scheduled end — the discount runs until someone removes the rate plan from the subscription. In Zuora it books the discount charge with no end date, so it applies for the life of the subscription. Because a permanent discount is a stronger giveaway than a time-boxed one, evergreen is **off by default** and must be enabled per journey. When it's off, a CSR cannot grant one — the option simply isn't shown, and the server refuses a no-duration concession. An applied evergreen concession shows as **"Evergreen"** rather than a period count, and its ledger entry has no end date. ## Guardrails at apply time Two limits are re-checked against live data at the moment of commit, not trusted from the preview — another staff member may have granted something in the meantime: * **One active concession per subscription.** * **A re-offer window** — a subscription that received a concession recently can't get another one until the window elapses. Every attempt is written to the concession ledger, including failures. A concession a CSR believes they granted that never reached the billing system is recorded as failed and surfaced, never swallowed. ## What downstream systems receive On success the journey publishes a set of concession context variables — band, GL label, type, value, scope, duration, end date, reason, note, who applied it and when, and the computed per-period and total value. These are available in **Variables** and can be mapped like any other context value into field mappings, CRM writes, or webhooks. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.peakcommerce.com/product/journeys-and-pages/journey-steps/concessions.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.