Having a Module and Offering It to Clients Are Different Switches

Paying for a Module Is Not the Same as Selling It on the Portal

A facility owner enables training in billing because the head trainer has been asking for enrollment records for six months. Checkout succeeds. Staff see training admin the next morning. By Friday an owner taps Training in the portal and tries to book a board-and-train spot the desk never meant to sell online.

Nothing is "broken." The org is entitled to training. The owner portal still lists every entitled module by default. Billing answered "do we have this product?" Client Portal never got the separate question: "do we want owners to see it at this location?"

Those are two switches. Treating them as one is how multi-service kennels launch modules before front desk, trainers, and portal copy are aligned.

What Entitlement Actually Controls

Entitlement means the organization has the module on its plan. Training, boarding, grooming (when you add it), and the shared core all flow from that layer. Staff routes under module admin exist because entitlement is true. Session notes, enrollments, and invoices for that service line are legitimate work in the building.

Entitlement does not mean every owner at every location should see a self-serve path into that work. A trainer piloting structured intake on paper is entitled to use admin. That is not the same as opening the training tab on the owner app because a checkbox in billing flipped on.

Operators who run boarding plus programs need both truths at once: staff can execute, owners only see what you have priced, staffed, and described.

What "Offered to Clients" Changes

Offered to clients is a per-location decision on the Facilities Client Portal screen. Each location's "What we offer" card carries an Offered to clients switch. For orgs with more than one site, a module-by-location matrix sits above those cards so downtown can sell training while the satellite location stays boarding-only on the portal.

When a module is not offered at a location, the owner experience changes in predictable ways. The bottom nav drops that service. Dashboard calls-to-action for it disappear. Direct URLs such as /client/training bounce back to the home dashboard instead of showing a half-built booking flow. Portal APIs answer with a clear module not offered response rather than letting someone wedge into a workflow you have not staffed.

Staff admin is not gated by that flag. Hiding training from owners does not lock trainers out of enrollments. That separation is deliberate. Internal rollout can run while the portal stays quiet.

Defaults That Surprise People on Go-Live

Every entitled module defaults to visible on the portal. If you have never touched Client Portal settings, owners see what billing enabled. Absence of a customized card still means offered. The safe sequence for a soft launch is: turn Offered to clients off (or hide the module on the matrix for that location) before you tell the team the portal is live for that service.

Unentitled modules do not get a friendly off switch on that screen. They show Add it in Billing because there is nothing to offer yet. That UI detail matters when you are auditing a demo org. A greyed card is not the same as a hidden entitled module.

Grooming follows the same pattern once it is on your plan. Pet Ops grooming is coming soon as a full product surface; the visibility model already exists so you are not forced to sell a module the day entitlement turns on.

A Concrete Rollout: Two Locations, One Training Program

Picture Riverside Kennel with a main campus and a annex that boards only. Training runs at the main building. The owner enables training org-wide after hiring a second trainer.

Week one: trainers build program templates and run two in-house dogs through enrollments. Front desk is still quoting training by phone because pricing on the portal card is draft copy.

If Offered to clients stays on at both locations, an annex client who boards every month can open the app, see Training, and submit a request the annex cannot fulfill. Desk staff spend Monday untangling "I thought I enrolled online" threads that entitlement alone caused.

The fix is operational, not a refund. On Client Portal, leave training offered at main and off at annex until annex staff are trained on how to redirect or transfer leads. Keep admin work at main uninterrupted.

Week three: marketing pushes a board-and-train link. Main's portal card gets final title, description, and imagery. The switch flips on only when the enrollment call script and trainer capacity match what the button promises.

That sequence is boring. It prevents the more expensive failure mode: owners who believe your software lied because a billing toggle implied a product was ready.

How This Differs From "Turning a Module Off" in Organization Settings

There is a third layer worth naming so you do not mix metaphors on the same call. Organization Modules can hide a product from the admin navigation without revoking entitlement. That is an internal visibility choice for clutter, pilot discipline, or pausing a line while you keep historical data.

Hiding admin navigation does not automatically change what owners see. Conversely, hiding a module from clients does not remove staff access when entitlement remains on.

Evaluation teams should script all three questions in a demo:

1. What happens to staff menus when entitlement is on but the org hides the module?
2. What do owners see when entitlement is on but Offered to clients is off at their location?
3. What breaks (desk scripts, trainer capacity, portal copy) if you turn client offering on before question two has an answer?

If a vendor collapses those into a single "enable module" button, you will rehearse the wrong cutover.

Switching Software Without Re-Learning This Lesson

Migration week is when the switches get dangerous again. Importers move pets, owners, and open reservations. Entitlements get turned on so staff can work. Marketing republishes the portal link. Someone checks "training enabled" in the new system and assumes owners will not see it until launch day.

Copy the visibility matrix from your runbook, not from memory. For each location, document which modules are entitled, which are offered, and which are still staff-only. Pair that sheet with your kennel software alternative cutover checklist so the first owner login matches what the desk was told to promise.

When you compare vendors, ask where client offering lives. If it is buried inside billing with no per-location override, you will recreate Riverside's annex problem in the new tool.

How This Connects to Daily Operations

Multi-service facilities fail in the gap between "we bought the module" and "we are ready for owners to book it." Entitlement keeps trainers and kennel staff on one platform. Offered to clients keeps the portal honest about what each building sells today.

Your multi-service pet business software pillar is the argument for one core with distinct service lines, not one blur of tabs. Training that shares pets and owners with boarding still needs enrollments, session history, and owner updates that behave like board-and-train work, not like a boarding reservation with a longer end date.

Before the next module goes live, walk Facilities Client Portal for every location. Billing is step one. Offering is step two. Only then should owners get the button.

When you are still choosing systems, use a compare demo script that includes hiding training from the portal while staff run a real enrollment. If the product cannot show that split cleanly, you will pay for the confusion after signature.