Why International Mobility Platforms Need More Than SaaS

For the last two decades, “Give the team a login and let them figure it out” was a perfectly good way to sell software. SaaS priced by seat, delivered a dashboard, and left the operational work—actually getting things done—to the humans on the other side of the screen. That model made sense when software's job was to organize information a team still had to act on manually.

International mobility never really fit that model. It just didn't have a better option until recently.

The problem with per-seat software for mobility

A university international office, a corporate global mobility team, or a relocation agency doesn't need another dashboard to check. They require housing found, leases managed, payments reconciled, and problems solved for the person actually relocating—a student, an employee, a family moving across a border. A login doesn't do any of that. A person using the login does, and that person's time is the actual bottleneck, not the absence of software.

This is why so many mobility teams end up with software everyone logs into and a set of spreadsheets everyone actually uses to get the work done. The software organizes; it doesn't operate.

What changes with AI in the loop

The reason this is worth revisiting now, specifically, is that AI removes the constraint that made per-seat software the only viable model: a human had to be the one interpreting information and taking action on it, one case at a time.

An AI layer that can match a relocatee to available housing, flag a document that's missing before it becomes a delay, or answer a routine question at 11pm on a Friday isn't a better dashboard. It's doing the actual operational work a coordinator used to do manually—which means the value isn't in who has a login anymore. It's in what gets handled without anyone needing one.

From software you use to infrastructure that runs

The distinction we'd draw is this: SaaS sells access to a tool and assumes your team does the operational work. A hub model takes on the operational work directly—housing sourcing, documentation, communication with the relocatee, and  reconciliation with finance—and gives your team visibility into outcomes rather than a set of tasks to perform inside a dashboard.

Concretely, for a university, a corporate mobility team, or an agency, this looks like:

• Not logging in to manually match a student to housing, but seeing that the match has already happened and simply confirming or overriding.

• Not chasing a missing document by email, but getting flagged only when something actually requires a human decision.

• Not reconciling payments across three systems but seeing a single reconciled view because the reconciliation already happened.

The software is still there. It's just not the product anymore. The outcome is.

Why we're still pricing it like SaaS, for now

To be direct about something we don't hide: our pricing model still uses familiar SaaS benchmarks—tiers, annual licensing per-relocatee assumptions—because that's the language procurement teams and finance departments already know how to evaluate and budget against. Changing the pricing convention and the operating model at the same time would ask institutional buyers to trust two unfamiliar things at once. We'd rather earn that trust on the operating model first.

But internally, and increasingly in how we build, the story we're building toward isn't “software you subscribe to.” It's a hub: the layer that sits between housing and service providers on one side and the institution or the relocatee on the other, doing the operational work that used to require a team scaling headcount every time volume grew.

That's the direction international mobility infrastructure is heading, whether the pricing page says “SaaS” on it yet.

Frequently Asked Questions

• Is Floweal a SaaS platform?
  It's priced and licensed using familiar SaaS conventions, but operationally it functions as a hub—it takes on housing sourcing, documentation, and coordination directly rather than just giving your team a dashboard to work from.
  

• What's the actual difference between a hub and traditional SaaS?
  SaaS sells access to a tool and assumes your team does the operational work inside it. A hub model does the operational work itself and gives your team visibility into outcomes.
  

• Why keep SaaS pricing language if the operating model is different?
  Because procurement and finance teams already know how to evaluate SaaS pricing benchmarks, changing the pricing convention and the operating model at the same time would ask buyers to trust two unfamiliar things at once.

We make it flow.