Performance cycles ================== The **Performance** screen (sidebar → *Performance*) carries a **Design | Operate** switch at the top, the same split as Commissions: * **Design** — the reusable library you build once: the reward **programs** (and, over time, rule templates and tier bands) that cycles draw on. * **Operate** — the run: the **cycles** you compute, approve and settle, and the producer **scores** leaderboard. A **cycle** is the heart of the Operate side. It covers a period (annual, quarterly or monthly) and carries everything that happens in it: the **goals** you set, the **rewards** that pay on top of them, the **earnings** the platform computes, and the payouts you **approve and pay**. .. note:: Performance now hosts what used to be three separate screens: **Reward Library** is *Design → Reward programs*, and **Scorecards** is *Operate → Scores*; their old ``/rewards`` and ``/scores`` links redirect into the toggle. Production goals are the **Goals** of a cycle, and old ``/targets`` links redirect here. The cycle list -------------- The Performance screen lists your cycles — name, period type, dates, elapsed progress and status — with a search box and status/period filters in the header. Click a cycle to open its workspace; **New cycle** creates one and takes you straight into it. .. figure:: images/perf-cycles.png :alt: The Performance screen listing production cycles with their period, dates, elapsed progress and status. :width: 100% The **Performance** screen lists your cycles (Annual or Quarterly) with how much of the period has elapsed and their status. Open one to design its goals and rewards and settle its payouts. The cycle workspace and the flow rail ------------------------------------- Opening a cycle drops you into its **workspace**. The heart of it is the **flow rail** across the top — the four moves of a cycle, in the order you make them, each doubling as a live status read-out: .. figure:: images/perf-earnings.png :alt: The cycle workspace showing the Goals, Rewards, Earnings and Approve & pay flow rail above the producer roster. :width: 100% The **cycle workspace**. The flow rail — **Goals → Rewards → Earnings → Approve & pay** — is the primary navigation; below it, the **Earnings** step shows every producer's journey through the cycle. A single **Recompute** runs the whole pipeline. .. list-table:: :header-rows: 1 :widths: 22 18 60 * - Step - Whose move - What it is * - **Goals** - You set - The goal lines — who should produce how much. * - **Rewards** - You set - The reward rules that pay on those goals. * - **Earnings** - System computes - What each producer has earned so far, from their attainment. * - **Approve & pay** - Producer gets - The settlement queue — approve each award, then pay it. One action drives each step (**Add goal**, **Apply reward**, **Grant award**), and a single **Recompute** in the header runs the full pipeline — refresh attainment, then recompute every reward's awards — so you never have to remember which piece to update. Cycle statuses and actions ~~~~~~~~~~~~~~~~~~~~~~~~~~~~ .. list-table:: :header-rows: 1 :widths: 12 46 42 * - Status - Meaning - Header actions * - Draft - Being set up; attainment not yet tracked. - **Activate** * - Active - Goals in force; attainment and awards are computed. - **Recompute**, **Close cycle** * - Closed - The period is over; attainment stops. - **Reopen** .. _goals: Goals ----- The **Goals** step holds the cycle's goal lines — *one row per target: who should produce how much*. On a draft cycle, **Add goal** builds them; on an active cycle, attainment is measured against them. .. figure:: images/perf-goals.png :alt: The Goals step listing each goal line with its subject, metric and target value. :width: 100% The **Goals** step. Each row is one goal: a **subject** (producer, team or tenant), the **metric** it measures and the **target** value. Attainment rolls up automatically from the production ingested from your PAS. Each goal is defined by: Subject Who the goal applies to — which also decides how actuals are counted (the roll-up): * **Producer** — the producer's own production **plus their entire active downline's**, so an agency's or MGA's goal reflects its whole network (see :doc:`hierarchy`). * **Team** — the combined production of every producer on the team. * **Tenant** — all ingested production across the tenant. Metric **Written premium**, **New business premium** or **Policy count**. Target The goal value (greater than zero), with optional **Stretch** and **Floor**. Premium goals are denominated in a **currency** (defaulting to the tenant base currency); production in other currencies is converted at attainment time, and a goal with a missing exchange rate is skipped and flagged. Policy-count goals carry no currency and count **distinct in-force policies**: a policy written and then cancelled within the period nets out (it does not count), and several transactions on one policy count once, not once per transaction. Scope Optional **Product** and **Jurisdiction** filters narrow what production counts; leave them empty for *all business*. Once the cycle is active, each goal shows its **actual**, **attainment %** and a **pace** pill judging progress against time elapsed — **ahead** (green), **on track** (blue) or **behind** (red) — plus a straight-line **forecast** of the end-of-period value. Attainment is **recompute-driven**: a background job refreshes it regularly, and **Recompute** forces it on demand. .. _reward-library: The Reward library ------------------ Rewards are defined once in the **Reward library** (sidebar → *Reward library*) and then applied to as many cycles as you like. A library entry is a **program** — the umbrella for a class of rewards. .. figure:: images/reward-library.png :alt: The Reward library listing reusable reward programs with their type, award count and active status. :width: 100% The **Reward library**. Each program has a type — **Bonus**, **Contingent commission**, **Profit share** or **Contest** — an award count, and an **Activate** / **Deactivate** toggle. Only *active* programs can be applied to a cycle. Click **New program**, give it a **Name** and **Description** and pick a **Type**, then **Create program**. Programs are **active** or **inactive**: only active programs can be applied to a cycle, and deactivating one leaves its existing awards untouched. A program with awards cannot be deleted — deactivate it instead. .. _rewards: Rewards ------- The **Rewards** step of a cycle is where a program becomes an earning formula — *one row per rule: how a goal turns into money*. Click **Apply reward**, pick an active program and the metric and formula it should pay on: .. figure:: images/perf-rewards.png :alt: The Rewards step showing an applied reward rule with its metric, formula, the goals it pays and its state. :width: 100% The **Rewards** step. Each rule binds a reward program to the cycle on a **metric** and a **formula**, and shows how many **producer goals** it pays. Use **Manage reward programs** to jump to the library. Three formulas are available: * **Rate above target** — a rate on production *over* the goal value (e.g. 1.5% of written premium above target). The classic growth bonus. * **Rate on actual** — a rate on the *whole* production once attainment clears a threshold (the contingent-commission shape). * **Flat amount** — a fixed sum once attainment reaches the threshold; the only formula for policy-count goals. As you fill the formula, a **“Who this would pay”** panel previews exactly who earns and how much — a live dry-run against real production, so the estimate can't drift from what committing the rule actually produces. .. figure:: images/perf-apply-reward.png :alt: The Apply-reward dialog with program, metric and formula fields beside a live who-would-pay preview. :width: 100% **Apply a reward.** Choose the program, the metric it pays on and the formula; the **Who this would pay** panel previews the matching producer goals and what each would earn before you commit. Every producer-subject goal that measures the rule's metric earns its own award. Because awards are recomputed from live production, a *pending* computed award **follows the data** — it grows, shrinks or disappears as policies are ingested or reversed — until it is approved. Team goals have no single payee, so they don't pay. For anything a formula doesn't cover, **Grant award** (on the Approve & pay step) still creates a manual award. Earnings -------- The **Earnings** step is the cycle's roster — *who gets what, one row per person*. A summary strip reads **Producers**, **Avg attainment**, **Earned**, **To approve** and **Paid**; below it, every producer's row shows their progress, what they've **earned**, what's waiting **to approve**, what's **paid**, and **where they are** in the flow. Use **Group by** to switch between **Producer** (one row per person) and **Reward** (the same awards grouped by the rule that produced them). A producer below target on every goal reads *below target — no award*; there is nothing to pay and nothing to chase. .. _awards: Approve & pay ------------- The **Approve & pay** step is the **settlement queue**: every award waiting to be signed off and paid. A summary strip reads **In queue**, **Amount** and **Paid**; each row carries the single action valid for its status. .. figure:: images/perf-settle.png :alt: The Approve & pay step showing the settlement queue with pending and approved awards and their per-row actions. :width: 100% The **Approve & pay** step. Awards land here as *pending*; each row offers **Approve** (on a pending award) or **Mark paid…** (on an approved one). **Approve all pending** clears the queue in one move. An award's lifecycle is strictly ordered — no skipping, no going back:: pending ──approve──▶ approved ──mark paid──▶ paid (final) .. list-table:: :header-rows: 1 :widths: 15 85 * - Status - Meaning * - Pending - Computed or granted, awaiting sign-off. * - Approved - Signed off; awaiting the actual payout. **The amount is now locked** — later production restatement no longer rewrites it. * - Paid - The payout went out. Final — no further changes. Out-of-order actions are refused (you cannot pay a *pending* award, or approve a *paid* one). **Approve all pending** signs off the whole queue at once; **Grant award** adds a manual award for anything a reward rule didn't cover. Payout instructions ~~~~~~~~~~~~~~~~~~~~~ With **payout instructions enabled** (Settings), approving an award makes it **payable** — just as finalizing a statement does. A **payment run** then pays it: for an *immediate*-cadence producer the run fires at approval; for a scheduled producer the award waits and is consolidated with everything else payable on the producer's next run (:ref:`payouts `). Either way the payout is netted against the producer's debt and published to the PAS as part of one consolidated instruction — a bonus and a commission statement in the same currency ride the *same* deposit. Marking that instruction paid on the :doc:`commissions` Payouts tab flips every award it consolidated to *paid* automatically. Reconciliation: catching restatement ------------------------------------- Production keeps moving after awards are paid — policies cancel flat, premiums reverse, feeds are corrected. **Reconciliation** recomputes each computed award's *expected* amount from its rule and today's production and compares it to what was *actually paid*. The nightly sweep covers awards whose period ended within the **look-back window** (Settings, default 90 days), including awards on closed cycles. * **Matched** — the recomputed amount still equals what was paid. * **Variance** — the numbers diverge; managers get one notification per sweep listing the new variances. A variance never claws money back on its own. Review it on the award's detail page and, if a recovery is due, post a ledger adjustment (:doc:`commissions`) — the debt is then withheld from the producer's future payouts. Where a human judgment should stand (say, an agreed settlement), record a **manual reconciliation**; the sweep never overwrites a manual verdict. .. tip:: Set producer-subject goals at the level you manage: a goal on an MGA measures the MGA's whole network, so you don't need to duplicate goals down the tree unless you also manage the individual agents' numbers. Related ------- * :doc:`scorecards` ranks producers by a composite performance score and places them in tiers — a standing measure that complements a cycle's period goals. * :doc:`commissions` covers the signed rate cards, statements and payment runs that awards settle alongside. * :doc:`producer-portal` is where a producer sees their own awards and standing.