Answer joining, booking and billing questions from the terms already on file, book and move class places, and pass a cancellation request straight to the member-services staff who decide what is owed.
Ingest the request, the member's contract terms and the club's state configuration from supported sources.
02
Normalise membership types, add-ons and timetable references, and carry each term forward with its source.
Reason
03
Answer booking, freeze and billing questions from the terms already on file.
04
Apply the cancellation rules configured for the state the member contracted in.
05
Bind each answer to a clause in the agreement, and mark what the agreement leaves open.
Decide
06
Record a cancellation request the moment it is made, and suppress any save prompt.
07
Route a request carrying a refund or a statutory ground to named member-services staff.
Out
08
Retain the request, the terms it was answered from, the staff release and the confirmation.
09
Execute write actions only inside the approval boundaries agreed during implementation.
→Product statement
The agent answers and books; a member-services lead decides anything that changes what a member is owed, and the operator owns the state configuration.
Example workflow
One request, desk to release
AgentHuman
1Request receivedApp chat, web chat, front-desk hand-off or an inbound call
2Terms assembledContract clauses, membership state, add-ons and the timetable, each with its source
3Answer proposedBooking, freeze or request record, flagged terms and confidence
4Controls appliedContract-term checks, the state's health-club and auto-renewal rules, save-prompt suppression and confidence threshold
No human action required
Stages 1 to 4 run unaided, and nothing a member is owed changes at any of them — the agent is answering, and the staff lane opens at the confidence gate.
5DecisionBranches at the confidence threshold
High confidence
Goes to member-services staff to release.
Low confidence
Adds a club-manager read first.
Staff release
What is owed is held for staff, with the terms it was read against and the confidence.
Release · Correct · Send to the club manager
Released — the member is answered▼
6Club systems updatedOnly where write access and approval policy allow it
7Outcome evaluatedRepeat requests, corrections made at the desk, refund disputes and complaints raised after the fact
Corrections
Each staff correction is counted in the evaluation.
What should not run autonomously
Human approval stays in control
Outside the boundary — human approval required8 items
Deciding what a cancellation refunds.
Setting the date the billing stops.
Judging a relocation, medical or bereavement ground.
Registration, bonding and the signed contract.
Automation boundaryAgent acts unaided
✓Book, move and release class places against the live timetable.
✓Log a cancellation request the moment it is made.
✓Freeze a membership inside the documented policy.
✓Answer the terms already written into the member's own contract.
Any write happens inside the boundaries agreed at implementation, never ahead of release.
Whether a state's cooling-off window has run.
Anything the member's agreement does not already say.
Changing a price, a term or an add-on charge.
Changes to state rules or release boundaries.
Example output
One request, annotated
Everything the agent answers is attached to the terms it was read from.
Member-services output · single requestIllustrative example
Request
Answer given
Channel
Source of record
Confidence
Cancel path
Freeze request
A hold on the documented freeze terms of the member's own plan
App chat, where they joined
Membership agreement
93%
Shown, and unchanged
As receivedFrom the membership agreement and the state configuration — nothing here is decided.
The slice the aggregate hides is cancellation under a state cooling-off window — a thin share of the queue and most of the requests a member had to raise twice. Nestack reports the repeat rate by slice, not only in total.
Slice performance — reported separately, not only in aggregateIllustrative example
Slice
Failure rate
Lift
Lift vs. threshold
Status
Cancellations under state cooling-off
5.3%
3.4×
Review
Freeze and add-on requests
4.0%
2.6×
Review
Billing disputes mid-term
2.6%
1.7×
Watch
Class booking and rebooking
0.9%
0.6×
Normal
Bar: repeat-request lift vs. the class-booking baseline · scale 0–4.0× · tick marks the 2.0× review threshold2 of 4 slices over threshold
Evidence-linked improvement
The cycle closes on a test, not a note
A cycle closes when the failure is a regression case the next release has to pass. That suite is what the next request through the desk is measured against.
Improvement cycle · five stagesSwitchback — the path turns at Improve and returns at Learn
01Detect
Repeat requests rise in one request type.
02Diagnose
The request record is where this starts: what was asked, what terms it was read against, who released it.
03Improve
The change ships against a version, with the requests that exposed it attached.
04Verify
Release is blocked until the affected regression cases pass again.
05Learn
The case joins the permanent suite and the front-desk playbook.
Learn → DetectThe return edge. The next detection is measured against a suite one case longer.
Typical build scope
Twelve workstreams across six weeks
The build scope read against the delivery timeline. Week structure follows the six-week plan — discovery, sources, request workflow, evaluation, integration, then production validation and handover.
WorkstreamWeek 1Week 2Week 3Week 4Week 5Week 6
01Request workflow discovery and boundary definition.
02Club-management and billing assessment.
03Health-club, auto-renewal and ROSCA rule mapping, per state.
04Member-record ingestion and normalisation.
05Answering logic and clause binding.
06Confidence scoring and refund routing.
07Member-services release workflow.
08Club-management and billing integration.
09Cancellation-path regression cases.
10Guardrails and release controls.
11Request-trail instrumentation.
12Deployment, documentation and Agent Care handover.
12 workstreams · 6 weeks · bar shows the weeks a workstream is active — several run in parallelFinal scope and sequence confirmed in discovery
Engagement tiers
What each tier includes
Rows are the capabilities named in each tier's scope. Higher tiers include everything below them.
Capability✓ in scope · — not at this tierPilotOne club, one stateProductionProduction club systemsAdvancedMultiple sites / states
Introduced at Pilot
Answering from your contract terms✓✓✓
Staff release✓✓✓
Request-handling baseline✓✓✓
Introduced at Production
Reporting by membership type—✓✓
Release workflow in your systems—✓✓
Approved write-back—✓✓
Club-management-system integration—✓✓
Introduced at Advanced
Multi-state and multi-site rollout——✓
Multi-stage desk approvals——✓
High request volume——✓
Multi-site desk controls——✓
Build priceFrom $5,000From $8,000Custom quote
Final build priceConfirmed after discovery based on integrations, workflow complexity, request volume, release controls and deployment requirements.
Separate from buildBuild pricing is separate from recurring Agent Care, which covers managed monitoring, evaluations, incidents and verified improvements after launch.
What we need from you
What you bring, and what we build with it
Each input maps to a piece of build scope and a week in the delivery timeline.
You bringWe build with it
01Your membership agreements and their terms→Contract-term mapping and answer configurationWeek 1
02Representative requests from a past quarter→Answering baseline, term extraction and clause bindingWeek 2
03The states you trade in and their cancellation rules→Per-state cancellation-rule mapping and the automation boundaryWeek 1
04Access to relevant APIs, feeds or exports→Club-management, booking and billing assessment, then integration setupWeek 2
05Requests you would not want repeated→Cancellation cases and failure-mode testingWeek 4
06Where a request must stop and wait for staff→Confidence scoring, refund-consequence routing, guardrails and release controlsWeek 3
07Named member-services staff to release requests→Staff release workflow, then pilot and production validationWeeks 5–6
Nothing else is requiredDeployment, documentation and Agent Care handover are ours.
Delivery timeline
Four phases across six weeks
Each phase sits on the weeks it actually occupies, and week 5 carries both evaluation and launch work.
PhaseW1W2W3W4W5W6
DiscoveryW1
BuildW2 – W3
EvaluateW4 – W5
Pilot & LaunchW5 – W6
Week focusW1Request workflow discovery, term mapping and the automation boundaryW2Source integration and the answering baselineW3Answering workflow, confidence logic and release controlsW4Evaluation suite, cancellation-path checks and failure-mode testingW5System integration, a pilot desk queue and targeted correctionsW6A live desk queue answered under supervision, then Agent Care handover
Reading the bandA band covers the weeks its work is named in and no others. The doubled fifth week is real, not padding.
At the end of W6Validation closes on live requests, and Agent Care picks up monitoring.
DurationSix-week plan shown · typical delivery 4–6 weeks depending on scope confirmed in discovery.
Next step · Sports & Fitness AI agent
Build a member-services agent around your club's own terms.
We'll map the request path, set the automation boundary and name what stops for a person. Bring your contract terms, the states you trade in and whoever signs cancellations off today.
