AltoSignal for Spas

When the hotel wifi drops, the treatment rooms still hear the front desk.

Every screen in your spa passes each signal straight to the others across your own network, while a second copy goes through the cloud. If the internet goes down, therapists and the front desk keep signaling, and nobody has to switch anything.

That matters most where the network is someone else's: a resort spa on the hotel's wifi, or a studio on a consumer router, with nobody on site who can fix it.

What this changes

Three things an owner can check off.

  • 01

    Nothing to install in the spa

    It runs on the tablets and phones your team already uses. No server in a back room, nothing loaded onto the front desk computer, and no IT visit to schedule.

  • 02

    One account covers every location

    A group with three properties runs all of them from one account, with one place to manage staff, rooms and channels.

  • 03

    Signals travel locally and through the cloud at once

    A signal crossing the hall takes the short trip instead of the long one out to a data center and back. If the connection drops, signaling keeps working.

Both paths, every signal

{{ statusLine }}
THE CLOUD ✕ YOUR SPA NETWORK Front desk sends direct Treatment 1 Treatment 2 Housekeeping A browser screen receiving waiting for the connection cloud only, never direct
{{ explain }}

What keeps working, and what waits

Said plainly, because it is a trade and not a magic trick.

Keeps working

Signaling your team

  • +Signaling from any screen on the spa network
  • +Receiving it on the other screens on that network
  • +The buttons, rooms and channels already on the board
  • +Setting and reading room states between those screens

Waits for the connection

Changing the setup

  • +Editing button labels
  • +Adding or removing a channel
  • +Rebuilding the board layout
  • +Anything to do with your account or plan

That is the honest shape of it. What your team uses every minute keeps working. What an owner or manager touches a few times a year waits until the connection is back.

Built for the person who runs the network

Quiet by design, and switchable when a policy says so.

The IT manager of a 26-location eye care group came to us after the paging system he had inherited flooded the office network with multicast traffic and knocked out the VoIP phones he had just installed. He moved it to its own VLAN and the traffic still leaked. The vendor told him the software was still on .NET 4 and broadcast to everything. He replaced it with AltoSignal. A resort spa on the hotel’s network, or a studio sharing a router with the front-of-house systems, has the same person to answer to.

Local delivery here is a small discovery beacon and direct one-to-one connections on a single port, 49374, encrypted end to end with a key that belongs to your account. There is nothing to flood: a signal is a few hundred bytes to the screens that should hear it.

And when a network policy wants none of it, it is one switch, on the Account screen of any signed-in device:

Per screen

Use local network delivery

  • +Off for this screen only, for example a tablet on the guest network
  • +Stored on the device; every other screen is unaffected
  • +Signals still arrive over the internet

Whole account

Allow local network delivery

  • +Off for every screen on the account, from any one of them
  • +No screen can switch it back on while the account says off
  • +The cloud path carries everything; the only cost is a fraction of a second
The Account screen on a Fire HD 10: This device with the box Use local network delivery, Channels, Account with the box Allow local network delivery, and Session with Sign out.
The Account screen on a treatment-room tablet. The device switch under This device, the account switch under Account.
One switch.
Two paths, every send.

Setting it up is nothing

There is no step here. That is the whole feature. Screens find each other on the network by themselves: no fixed addresses to assign, no router settings to open, no server to stand up.

Networks do vary, and some configurations stop devices from discovering each other. On a typical spa network it works with no setup at all, and the cloud path carries every signal either way.

Where it runs

Local delivery runs in the AltoSignal app on tablets, phones and desktops. Those are the screens that hand signals to each other directly.

The browser version keeps working everywhere and still needs nothing installed, which is what makes it useful for a spare screen or a quick sign-in. It does not take part in local delivery, so a browser screen receives through the cloud. See which apps run where.

Fast inside the building, or able to reach past it.

Call systems that live entirely inside one building are quick and dependable for exactly that reason. It is also why they cannot reach a second location, why something has to run on site, and why putting one in and keeping it going takes somebody technical.

Signaling that lives in the cloud reaches anywhere and installs nothing. It also stops when the internet does.

AltoSignal does both, from one account. That is the argument for a group.

About local delivery

Is there anything to install or configure?

Nothing, and there is no step to skip. Devices find each other on the network by themselves: no fixed addresses, no router settings to open, no server in a cupboard, nothing loaded onto a back office PC. Sign in on a screen and it joins in. Networks do vary, and some configurations stop devices from discovering each other; on a typical spa network it works with no setup at all, and the cloud path carries every signal either way.

So AltoSignal works without internet?

Not as a blanket statement, and we would rather be exact than flattering. Signaling between screens on the same network keeps working. Signing up, changing your plan and anything that touches your account still needs a connection, because those live in the cloud. What keeps running is the part your team uses every minute.

Does someone have to switch it over when the wifi drops?

No, and there is nothing to switch. Both paths carry every signal all the time, so the local one is already carrying it before anything goes wrong. Nothing watches for an outage, nothing fails over, and there is no state for your team to be aware of.

Does the browser version do this?

No. Local delivery runs in the AltoSignal app on tablets, phones and desktops, and those are the devices that hand signals to each other directly. The browser version keeps working and still needs nothing installed, which is what makes it useful for a spare screen, but it receives through the cloud.

What about a spa with two locations?

Both halves apply and they do not fight. Screens inside each building hand signals to each other directly, and the cloud is what carries a signal between one property and another. That is the combination a system living entirely inside one building cannot offer at all.

Can we turn local network delivery off?

Yes, and the reason the switch exists is a story we heard from the IT manager of a 26-location eye care group. The paging system he had inherited flooded the office network with multicast traffic and knocked out the VoIP phones he had just installed; he moved it to its own VLAN and the traffic still leaked. AltoSignal's local path is a small discovery beacon and direct encrypted connections on one port, so there is nothing to flood, and when a network policy wants none of it there are two switches on the Account screen: Use local network delivery, for one screen, and Allow local network delivery, for the whole account, which no screen can override. Signals still arrive over the internet either way.

Put it on the screens you already own.

Thirty days free, on every screen in the spa. Nothing to install on your network and nobody to call.

Start 30-day free trial