Interpret GymCore statuses before acting.
A status describes one part of a record, not the whole customer journey. Read the customer-facing label first, then use the stored value below when handing a case to support or engineering. Do not change a database value simply to make a screen look resolved.
Lead pipeline
| Status group | Stored values | Default | What it answers |
|---|---|---|---|
| Pipeline stage | `lead`, `trial_booked`, `trial_attended`, `offer_made`, `converted`, `lost` | `lead` | Where the prospect is in the commercial journey |
| Contact status | `new`, `first_attempt_due`, `first_attempted`, `contacted`, `waiting_on_reply`, `stale` | `new` | What staff have done to reach the lead |
| Trial status | `not_scheduled`, `requested`, `scheduled`, `confirmed_24h`, `confirmed_day_of`, `waiver_pending`, `waiver_complete`, `checked_in`, `no_show`, `reschedule_needed`, `cancelled` | `not_scheduled` | What happened to the trial appointment |
| Sales disposition | `none`, `membership_offer_sent`, `started_free_trial`, `comeback_appointment`, `not_interested`, `bad_fit`, `duplicate`, `invalid` | `none` | The sales outcome or next commitment |
| SMS consent | `unknown`, `opted_in`, `opted_out` | `unknown` | Whether SMS contact is permitted |
| Email consent | `unknown`, `opted_in`, `opted_out` | `unknown` | Whether email contact is permitted |
The trial-appointment store uses the actionable trial values from `scheduled` through `cancelled`; a lead can still have `not_scheduled` or `requested` before an appointment row exists. A blank Lead Pipeline is a real empty state, not proof of a rendering error.
AI proposed actions
| Stored value | Meaning |
|---|---|
| `pending` | Waiting for staff review |
| `approved` | Approved for dispatch or processing |
| `approved_with_changes` | Staff edited and approved it |
| `completed` | The action processor recorded completion |
| `rejected` | Staff declined it |
An action JSON record is the machine-readable set of proposed action details. Owners should use the visible approval queue; engineers may inspect that record when diagnosing. “Completed” is a local action state and must still be compared with the destination system, such as the SMS provider, WooCommerce, or a published post.
Other operational statuses
| Record | Stored values/default | Source boundary |
|---|---|---|
| Tournament | Blank until selected; `upcoming`, `open`, `closed`, `completed` | WordPress tournament post meta |
| Class occurrence | `active` by default; `cancelled`, `suspended` | GymCore class-occurrence row; WordPress post publication is separate |
| Membership pause | `active`, `resumed` | GymCore pause record; WooCommerce subscription may separately be `on-hold` or `active` |
| QuickBooks sync | `success`, `error`, `skipped` | GymCore sync log only; QuickBooks owns the accounting result |
| QuickBooks entity | `order`, `refund`, `payout`, `failed_retry` | Identifies the attempted operation, not its success |
| License badge | Active, Expired, Invalid, Not Activated | Cached local license state; compare with getgymcore.com |
Communication provider statuses can change after GymCore first records a message. The configured provider’s latest delivery event is the final delivery source.
Exact steps
Safe stop: Read and compare the owning records without changing a status; stop when no supported transition exists instead of editing a stored value directly.
-
Record the customer-facing label, stored value if visible, record ID, and timestamp.
Expected: You can identify both the status group and the exact record it describes.
-
Open the owning record: lead, trial appointment, AI approval, tournament post, class occurrence, pause, WooCommerce subscription, or QuickBooks transaction.
Expected: The source record shows whether the status is current, stale, or describing only one part of the workflow.
-
Compare related records by ID and time rather than forcing their labels to match.
Expected: A trial, lead stage, sales disposition, and consent state can legitimately differ because they answer different questions.
-
Use the supported customer action that produces the desired transition, then reload the owning record.
Expected: The source record records the new state and related logs show the transition. If no supported transition exists, preserve the record and escalate; direct status edits can skip consent, billing, or notification side effects.
Symptom examples
- A lead at `converted` with SMS `opted_out` is not contradictory; membership and communication permission are separate.
- A local AI action at `completed` with a provider error still requires delivery investigation.
- A pause row at `resumed` while a WooCommerce subscription remains `on-hold` indicates a cross-system mismatch.
- A tournament with blank status will not automatically become `upcoming`; select and save the intended status.
Verified against: current lead constants, trial appointment store, AI pending-action store, tournament/class/pause models, QuickBooks sync log, and license UI.
Need help?
Describe one problem and the installed versions. Never send passwords, license keys, API keys, payment details, or member records.