# The person logging in is not always the customer.

**Author:** Ivan Misic  
**Published:** 2026-08-16  
**URL:** https://ivanmisic.net/blog/product/person-logging-in-not-always-customer

**TL;DR**

Authentication tells you who is present. It does not tell you what that person owns, what they may manage, or which customer is placing the current order. Treat those as separate questions.

A person signs in and looks at a mobile subscription. It is easy to call them “the customer” and move on, until the real cases turn up.

The subscription belongs to their employer. The broadband contract is in their partner's name. They pay the household bill but cannot change the plan. They are allowed to buy an add-on for one service, but not renew another. They start an order on behalf of a company and need the invoice attached to that company, not to themselves.

These are not edge cases. They appear as soon as the product supports households, delegated access, or business accounts. They only look unusual when the product model assumes that one login equals one customer.

## Five nouns that teams collapse into one

The word “user” often covers five different things:

- the person who authenticated
- the customer record holding the commercial relationship
- the owner of a particular service
- the person allowed to act on that service
- the customer under whom a new order will be created

Calling all five things “the user” works only while the product is simple. Once it adds households, business accounts, or delegated access, each noun answers a different question.

| Concept | Question it answers |
|---|---|
| Logged-in user | Who proved their identity? |
| Customer | Which commercial relationship are we looking at? |
| Service owner | Who legally or commercially owns this service? |
| Permission | What may this user do here? |
| Order context | Under which customer will this transaction be recorded? |

<figure>

![Relationship map separating the logged-in user from the customer, service, and order context](/images/blog/product/login-customer-context.png)

<figcaption>The order needs an explicit customer and service context. The login alone cannot supply either one.</figcaption>

</figure>

Separate the questions and the edge cases become normal relationships.

## Login is where the decision starts

An identity provider can tell the application who logged in. It still can't, by itself, tell the application whether that person may renew a partner's subscription or order equipment for a company account.

Login gives me an identity. I still need the customer context, ownership, and permission.

This is where a clean login flow creates a false sense of completion. The session is valid, so the team feels access is solved. It isn't. Authentication is solved. Authorization and commercial context are not.

> A valid session answers “who are you?” The product still has to answer “in whose name are you acting?”

That second question should be visible in the design. If the same person can act for more than one customer, the product needs an explicit current context. It should not guess it from the last service viewed, or from whatever the API returned first.

## Model relationships, not exceptions

The weakest implementation is a growing set of special flags: `is_owner`, `is_family_member`, `is_company_admin`, `can_pay`, `can_buy`. Every new journey adds another flag (and another meeting about what the flag means). Soon the interface and backend disagree because each one interprets the flags differently.

Model the relationships instead:

1. One authenticated identity can be linked to one or more customers.
2. Each link has a role or a defined set of permissions.
3. Services belong to a customer, not directly to the login session.
4. An action is evaluated against the selected customer, the target service, and the user's permission in that relationship.
5. A new order records both the acting identity and the commercial customer context.

Then the next journey adds a relationship, not another flag nobody fully understands.

It also makes the audit log readable. “Ivan changed the plan” is incomplete. “Ivan, acting as an administrator for customer X, changed service Y” is a record an operations or support team can actually use.

## Checkout is where the ambiguity becomes expensive

Browsing may tolerate a fuzzy customer context. Checkout cannot.

Before an order is submitted, the product needs clear answers to some unglamorous questions:

- Who will own the new service?
- Who is allowed to accept the terms?
- Which account receives the charge?
- Which address and eligibility rules apply?
- Who may later cancel, renew, or report a problem?

If the interface assumes the logged-in person is the buyer, that decision leaks into contracts, billing, delivery, and support. Fixing the screen will not fix orders created under the wrong customer.

I prefer to make the commercial context explicit before the irreversible step. The wording does not need to sound like a data model. A short “Buying for” selector or a clear account label can do the job. What matters is that the UI reflects a real choice instead of decorating a hidden default.

This gets harder in a multi-market app. Shared screens help, but they do not make identity and account relationships identical. I wrote about that broader tension in [Multi-market apps: the central vs. local paradox](/blog/digital-transformation/multi-market-apps-central-local).

## The APIs have to preserve the distinction

The interface cannot preserve a distinction the APIs throw away.

I look for three things in the integration design:

- the acting person and the commercial customer have distinct identifiers
- requests carry the customer and service the action is performed against
- the system records who acted, under which permission, and on whose behalf

If older systems use one identifier for both identity and customer, the integration layer should preserve the distinction for the product. The same principle sits behind my argument in [Build the API layer before replacing the billing system](/blog/digital-transformation/dont-replace-billing-system): give the interface a coherent model even when the underlying systems disagree.

The layer should translate the mess, not flatten it.

## A useful test before design starts

Take one important journey and replace the word “customer” in every step with a more precise noun.

Who logged in? Which commercial customer is selected? Who owns the service? What permission allows the action? Under whom will the order be stored?

If the team can't answer without inventing rules in the room, discovery still has work to do. The missing product model should not be dismissed as a backend detail.

Often the person logging in is the customer, owner, payer, and buyer. A good model handles that simple case and still works when the roles split.