Portal System, Subshop, or Standalone System: Which Structure Is Right for You? | The Basics of Interfaces with Tina · Part 3

Single-system model: One organization, clear lines of responsibility

The classic use case is a single business with its own online store.
The roles are usually clearly defined:

• The company sells its own products.
• Payments are made to a designated recipient.
• Gift certificates can be redeemed at our own location.
• Your own PMS or accounting system processes the data.

Compatible interfaces can be connected directly to the existing systems.
This keeps the processes relatively straightforward. Nevertheless, it should be clarified here as well which system is responsible for redemption, posting, and payment.

Connected Standalone Systems: Independent, but Not Isolated

Having multiple businesses does not automatically require a shared portal.
Even standalone systems can be connected to one another. This makes it possible, for example, to purchase a gift certificate at one business and redeem it later at another.

In this regard, certain issues must be clearly addressed:

1. Where was the gift certificate sold?
2. Where was it cashed?
3. How is the amount allocated?
4. How are transactions settled between the businesses?

This structure allows for independent applications and systems, while selected processes operate across the entire organization.

Portal System: Sell centrally, redeem locally

In a portal system, multiple companies or partners are connected via a shared platform.

A central marketplace is created for guests. They make purchases through a single store but can redeem their gift certificates at various partner businesses or locations.
That’s why the real challenge often begins after the sale.

Depending on the organization, the following must be clarified:

• which partner redeems the gift certificate,
• how payments are allocated,
• how revenue is recorded,
• how settlements are handled between headquarters and partner companies,
• what data is needed at the central level.

A portal system therefore requires more than just technical connections. It also requires a clear process for redemption, posting, and billing.

Subshops: A distinct online presence, a shared technical foundation

Subshops combine a central technical platform with individual storefronts.
Multiple businesses use a shared main system. They can still present themselves to the public with their own store sections.

Depending on the configuration, this allows you to:

• various designs,
• own product lines,
• Custom brand identities,
• separate responsibilities,
• Payment flows organized in different ways.

The technical infrastructure remains centrally organized. This structure may be particularly appealing for hotel groups, multiple locations, or different brands.
However, a shared technical foundation does not automatically mean that every process is handled centrally. Redemption, payment, and accounting can still be organized differently.

More interfaces aren’t necessarily better

With complex structures, there is often a strong desire to directly connect every system involved.
However, every additional connection also increases the effort required for setup, coordination, and maintenance.
Before proceeding with integration, the following should therefore be considered:

1. Which process should be automated?
2. How often does this process take place?
3. How much manual work is currently involved?
4. Which systems are actually involved?
5. What specific benefits does the interface offer?
6. Is there an easier solution?

In some cases, a direct interface saves a lot of operational work.
In other cases, a centralized process in the incert backend or mobile redemption may be the more streamlined option.

Tina’s System Check: Not every possible connection is a useful one. What matters is the process that it is intended to simplify.

First the architecture, then the interface

There is no single “correct” system structure.
A single business has different requirements than a hotel group. A portal functions differently than several interconnected individual systems. A subshop, on the other hand, combines a shared technical foundation with individual market presences.

Therefore, the question at the beginning should not be:

Which interface can we connect to?

A better question would be:

What structure best reflects our organization and our processes?

Only once this answer is clear can we decide which systems should communicate with each other and where an interface would provide real benefits.