> ## Documentation Index
> Fetch the complete documentation index at: https://docs.spirii.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Customers

> The organisation an operator serves, and the boundary that controls who sees what.

A customer is an organisation, or a private individual, that sits one level below an operator on the platform: the party an operator does business with, and the owner of the records tied to it.

<Frame>
  <img src="https://mintcdn.com/spirii-7457b714/Hq2YBNx3n8oQoC1s/images/components/customers.png?fit=max&auto=format&n=Hq2YBNx3n8oQoC1s&q=85&s=65ca1c843b8b92d9173ac0e21f94e6bb" alt="The customer info panel in Spirii Connect, showing a customer's ID, name, operator, owner, type, and country" width="909" height="562" data-path="images/components/customers.png" />
</Frame>

## Overview

An operator runs a service on the platform; a customer is who that service is *for*. Spirii's platform is built for 2 business models:

* A charge point operator (CPO) and the site owners whose locations it runs.
* An e-mobility service provider (eMSP) and the fleet owners whose drivers it serves.

Either way, the customer is the organisation one level down. It can be a business or a private individual.

Every main object in Spirii Connect (locations, tariffs, vouchers, tokens, and more) is tied to a customer. That link is also what governs access: a Spirii Connect user sees an object when it belongs to a customer they're permitted to see. So a customer is two things at once: a record of who owns what, and the boundary that decides who can see and manage it.

## Context

A customer means something a little different depending on the operator it sits under. Either way, customers live entirely inside Spirii Connect: the operator's own structure for ownership and access, not something drivers or roaming partners see.

### CPO context

When the operator is a charge point operator, its customers are the **site owners** whose locations it runs: the businesses, municipalities, or individuals that own the sites, the chargers, and the revenue they produce. A smaller operator working under a larger one can be a customer too.

### eMSP context

When the operator is an e-mobility service provider, its customers are the **fleet owners** it serves: the organisations whose drivers charge across the network. Here a customer owns the fleet's accounts, tokens, and access rather than physical sites.

## Key attributes

| Attribute   | Description                                                                                                  | Example      |
| ----------- | ------------------------------------------------------------------------------------------------------------ | ------------ |
| Name        | The company name, or a person's full name for a private customer                                             | `Acme Inc.`  |
| Type        | Whether the customer is a business or a private individual                                                   | `Business`   |
| Country     | The customer's single origin country                                                                         | `Germany`    |
| Owner       | Who the customer sits under: the operator, or another business customer. A private customer can't own others | `Operator`   |
| External ID | Your own reference for the customer, for use in internal or billing systems                                  | `CUST-10293` |

A customer also has a contact person, and can hold billing and payout details that are used when Spirii invoices the customer.

## Relationships

### Operators and customers

An operator sits above its customers. It can see every customer beneath it, while each customer sees only what belongs to it. Operators, whether CPOs or eMSPs, are set up and managed by Spirii.

### Parent and child customers

A customer can own another customer. A parent customer can see everything belonging to its children, which mirrors real group structures: a holding company over its subsidiaries, or a head office over its regional entities.

[The customer hierarchy](/capabilities/account/customer-management#the-customer-hierarchy) covers how you build the tree, and the one rule that constrains its shape.

### A customer is not a driver

In charging, "customer" often means the person plugging in. Here it doesn't: a customer is the organisation an operator serves, either a site owner or a fleet owner. The people who actually charge are app users and drivers, tracked separately.

## Used in

<CardGroup cols={2}>
  <Card title="Locations" icon="map-pin" href="/components/charging/locations">
    Each location is owned by a customer.
  </Card>

  <Card title="Tariffs" icon="banknote" href="/components/commercial/tariffs">
    A tariff is owned by a customer, or shared across all of them.
  </Card>

  <Card title="Vouchers" icon="badge-percent" href="/components/access/vouchers">
    A voucher group belongs to a customer.
  </Card>

  <Card title="Tokens" icon="key-round" href="/components/access/tokens">
    A fleet's tokens are tied to a customer.
  </Card>
</CardGroup>
