Wix and gym
The timetable advice that does not work here
Every piece of guidance for gyms says the same sensible thing: point the assistant at the timetable page you already maintain rather than uploading a snapshot that will be wrong in a fortnight. On this platform that advice quietly fails, because the timetable page maintains itself out of an app and the page itself contains almost nothing.
Why this pairing is its own job
The Wix install guide covers the tag, and the gym guide covers what the assistant has to know. What follows is the part that belongs to neither.
- The schedule is rendered by the booking app from its own data. A crawl of the timetable page returns the heading, the filters and the surrounding layout, and none of the class names, times or instructors, which is the entire content of the page as a human sees it.
- Membership options are held as pricing plans, and a plan carries a name, a price and a duration. The minimum term, the notice period and how notice must be given, which is where all the difficult traffic in this trade comes from, are not part of a plan and usually sit in a document nothing links to.
- The member area is a signed in part of the site, so the site wide snippet puts the launcher in front of members asking about their own account, which is the category of question the assistant has the least ability to help with.
- Class cancellation windows and no show penalties are enforced as settings in the booking app. The rule exists and is applied to members, but it exists as a number in a configuration screen rather than as a sentence anybody can read.
What changes about the install here
<script src="https://cdn.askably.xyz/w.js" data-key="pk_live_YOUR_KEY" defer></script>The tag is the same one on the Wix guide. Everything below is about where it goes on a gym site specifically.
The member area is a second audience wearing the same launcher
Members Area pages are pages of your site, so the snippet reaches them. That means the same launcher greets a prospect on the joining page and a member who has just signed in to sort out a payment, and those two people need completely different things.
Decide which one the assistant is for and write the greeting for that person. If it stays on the member area, the greeting has to say up front that it cannot see accounts, payments or bookings, because a member who assumes otherwise will type a payment question and read the refusal as the club dodging them.
Whatever you choose, make sure the handover route from a member area page reaches whoever handles memberships rather than a general enquiry address. A cancellation attempt landing in the wrong inbox is how a notice period gets disputed later.
Get the schedule into words, or accept that it cannot answer
There are two honest options and no third one. Either you maintain a written schedule page alongside the app, in which case the assistant can answer what time spin runs on Tuesday, or you do not, in which case the refusal should say plainly that the timetable is on the timetable page and link it.
The second option is more defensible than it looks. A stale answer sends somebody across town at six in the morning for a class that was cancelled, and that member does not come back to ask again. Saying go and look is worse service than a correct answer and considerably better service than a wrong one.
If you do maintain the written version, keep it coarse. Days, class names and times hold steady for a term. Instructor names and cover do not, so leave them out rather than committing to them.
Publish the terms that are not in a plan
Write one page that states the minimum term for each membership, the notice period, how notice has to be given, when the last payment falls and what happens if a payment fails. None of that lives in the pricing plan, and it is the material that decides whether a leaver becomes a complaint.
Add the freeze rules to the same page: whether a pause is possible, what it costs, how often it is allowed, and whether the minimum term extends by the frozen period. Members assume freezing is free and unlimited, and finding out from a chat reply is much better than finding out from a payment.
Where the answerable material lives
| A written schedule page, kept deliberately coarse | Days, class names and start times as text, published beside the booking app rather than instead of it. No instructor names and no cover arrangements, because those change weekly and a wrong one is worse than an absent one. |
|---|---|
| The terms the pricing plan does not carry | Minimum term, notice period, how notice must be given, when the final payment falls, what happens on a failed payment. The plan holds a price and a duration. This page holds everything a leaver actually asks about. |
| The class cancellation window, copied out of the settings | The app enforces a cutoff and a penalty. Write both down as a sentence on a public page, because a rule that is applied to members but never stated to them is the rule that generates the angriest messages. |
| What is only inside the member area | Anything published only on signed in pages is unreadable to a crawl, which usually includes the cancellation instructions themselves. If the only copy of how to leave is behind a login, prospects cannot be told the terms before they join, and that is the wrong way round. |
The first thing to get right
Publish the notice period and the minimum term on a public page and index it before anything to do with classes.
Leaving is where every difficult conversation in this trade starts, and a member who cannot find the notice period assumes it was hidden. Stating it plainly to everyone who asks protects the club at least as much as the member, and it is already written down in a contract nobody reads.
The failure that belongs to this combination
A launcher in the member area that cannot see the member
Somebody signs in, goes to the member area to sort out a payment that failed, and finds a chat launcher sitting there. They type the obvious thing: has my payment gone through. The assistant cannot see the account, cannot see the payment and correctly says so.
In that context the refusal reads as evasion rather than honesty. The member is signed in, on a page that clearly knows who they are, being told that the chat does not. That is a worse experience than no launcher at all on that page, and it produces complaints that get attributed to the club rather than to the arrangement.
Either write the greeting for a signed in member so the boundary is stated before they type, and route the handover straight to memberships, or run the tag on the public pages only and leave the member area to whatever the club already uses for account questions.
Before you go live
- The origin the page is served from has to be on the allowlist for that assistant, or nothing renders and the browser console says which origin was refused. An apex domain and its www are two different origins to a browser, so list both, along with any staging or preview host you want it to work on.
- Open the site as a visitor would, on the pages a gym visitor actually lands on, and ask it something only your own material could answer. A widget that renders is not the same as a widget that has read anything.
Questions
- Why can it not read our timetable when the page clearly shows one?
- Because the page and the schedule are two different things here. The booking app holds the classes and draws them into the layout when a browser loads it. What a crawl collects is the layout. The check takes a minute: ask the assistant when a specific class runs and look at what it cites.
- Can it cancel a membership for somebody?
- No, and it should not sound like it might. It can state the notice period and exactly how notice has to be given, which answers most of the traffic, then take a name, an email and a message through to whoever handles memberships. What it must never do is confirm that a particular membership has been cancelled or that a payment will not be taken.
- Should we index the member area pages?
- You cannot, in the ordinary way, because they are not served to anyone who is not signed in. If important terms only exist there, copy them onto a public page. Prospects deciding whether to join need the cancellation terms before they join, and a term that only appears after joining is the weakest kind to rely on.
Keep reading
- Installing on WixWix has a Custom Code panel for third-party tags. Apply it to all pages at Body end, load it once, and pick its consent category on purpose.
- Everything for a gymContract length and cancellation terms cause most gym complaints. Timetables, inductions and joining fees are worth automating.
- A dental practice on Wix, where consent decides who gets the assistantOn Wix the snippet loads only after a visitor accepts the consent banner, and the patient with a broken tooth at midnight is the one who dismisses it.
- A salon site where the prices are drawn rather than writtenWix draws service prices and durations from its booking app, so the page a crawl receives holds no prices. Publish a text services page too.
- A gym on WordPress, where the timetable is a container and the terms are a fileThe timetable block is filled in the browser, so a crawl of it reads an empty box. The notice period is in a PDF. Both decide what a gym assistant can say.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.