> For the complete documentation index, see [llms.txt](https://en.help.firstline.cc/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://en.help.firstline.cc/feature/admin/enterprise/sponsor.md).

# Owner

The owner feature supports BPO and multi-client service scenarios. By distinguishing ownership, it separates customers, tickets, channel categories, and related resources, helping the same customer service team maintain data boundaries for different clients.

「**Owner**"Owner" is mainly used to support business process outsourcing (BPO) or scenarios where the same customer service team serves multiple client companies at the same time.

Through the Owner, you can establish clear ownership relationships for customers, tickets, channel categories, and other data that support the Owner. When agents handle services for different companies, the system can use the corresponding Owner's data according to the current service context, reducing the risk of mixing data from different clients.

{% hint style="info" %}
The Owner is not another independent FIRST LINE environment, nor is it just a label used to display a company name. It is a**data ownership setting**that keeps the different business data within the same FIRST LINE environment under a consistent Owner.
{% endhint %}

## Why Owners are needed

Suppose an outsourced customer service center handles **Company A**and **Company B**customer service at the same time, and Ms. Tsai is a member of both companies.

In actual operations, Company A and Company B may each have different member data, contact records, tickets, and service processes. Therefore, even if it is the same customer in reality, FIRST LINE can still create separate customer records for each Owner based on the different Owners.

For example:

* When Ms. Tsai contacts through **Company A's service channel**the service process should use the customer and related data belonging to Company A.
* When Ms. Tsai contacts through **Company B's service channel**when contacting, it should use the data belonging to Company B.

Through Owner attribution, the same customer service staff can share FIRST LINE while still maintaining clear data boundaries for different client companies.

## How Owners work

The Owner first defines "which client this data belongs to," and then each function creates the corresponding Owner relationship.

A common workflow is to first assign the**channel category**to a specific Owner, and then bind the actual LINE, Facebook, phone, or other service channels to that channel category.

```mermaid
flowchart TD
    A[Owner A] --> B[Channel Category A]
    B --> C[LINE / Facebook / Phone and other channels]
    C --> D[Customer inquiry or proactive contact from an agent]
    D --> E[Service context takes over Owner A]
    E --> F[Customer / service records / tickets / related resources]
```

This design reduces the need for agents to manually determine the Owner each time they provide service, and allows subsequent data to reuse the same Owner context as much as possible.

{% hint style="success" %}
**Recommended implementation approach**

If the company mainly distinguishes clients through different LINE, Facebook, and phone channels, it is recommended to first create Owners, then set the Owner for each "channel category", and finally bind the actual service channels to the corresponding channel categories.
{% endhint %}

## Which data uses Owners

Owners appear in multiple functions, and different functions use Owner attribution or filtering according to their own purposes.

| Function         | Main use of Owner                                                                                                |
| ---------------- | ---------------------------------------------------------------------------------------------------------------- |
| channel category | Specify the Owner served by this category as an important source of Owner information for subsequent services.   |
| Customer         | Record which Owner the customer data belongs to, to prevent customer data from different clients being mixed.    |
| Ticket           | Record the Owner of the ticket and maintain a consistent customer-Owner relationship in related operations.      |
| Service record   | Keep the Owner of the service for easier future lookup and filtering.                                            |
| Knowledge base   | Applicability can be established by Owner, allowing service contexts to use the corresponding knowledge content. |

{% hint style="info" %}
Different functions may apply Owners in different ways. Some data inherit the Owner from the service process or existing relationships, while some data can be specified by administrators or agents when creating the data.
{% endhint %}

## The same customer can belong to different Owners

The Owner structure is especially suitable for BPO scenarios because "the same natural person" does not mean "the same enterprise customer record".

For example, when Ms. Tsai is a customer of both Company A and Company B, the following can exist separately:

| Owner     | Customer data         |
| --------- | --------------------- |
| Company A | Ms. Tsai of Company A |
| Company B | Ms. Tsai of Company B |

The two records can be maintained separately according to each company's member information, service records, and follow-up tickets.

Therefore, when planning Owners, you should understand the Owner as**the ownership boundary of business data**rather than simply using personal information such as name or phone number to judge whether customers are the same record.

## Creating and managing Owners

You can go to "Owners" under "Applications" in the left menu to create and modify them.

When creating an Owner, the following information is mainly configured:

| Field       | Description                                                                                                                             |
| ----------- | --------------------------------------------------------------------------------------------------------------------------------------- |
| Name        | The name used to identify the Owner. It is recommended to use the actual client company, brand, or a name consistently used internally. |
| Description | Supplementary information about this Owner's purpose, service scope, or other management information.                                   |

After creation, you also need to establish the corresponding relationships in channel categories, customers, tickets, or other functions that support Owners before the Owner settings will be applied further into the actual service process.

## Example usage scenario

Suppose a customer service center serves three brands at the same time:

* Bank A
* E-commerce B
* Insurance C

You can create three Owners separately and set each brand's channel categories and service resources to the corresponding Owner.

When a customer of Bank A contacts through Bank A's LINE, the service will proceed under Bank A's Owner context; when the agent later creates or looks up the customer, service record, and ticket, the same Owner attribution can be maintained.

Another agent, even if responsible for E-commerce B at the same time, does not need to set up another FIRST LINE environment for each brand, but can handle data for each Owner within the same system according to different service contexts.

## Planning recommendations

Before introducing Owners, it is recommended to first confirm the company's actual data and service boundaries:

1. **Use the genuinely distinct client parties as the unit**For example, different companies, brands, or independent operating units.
2. **First organize channel ownership**Confirm which Owner each LINE, Facebook, phone, or other channel should belong to.
3. **Do not treat Owners as general category labels**If you only want to distinguish service topics or case types, you should prioritize other functions such as service tags and categories.
4. **Establish a consistent naming convention**The same Owner should use a consistent identification method in channel, customer, and ticket settings.
5. **Confirm data relationships before creation**If existing customers or tickets need to be reassigned to a different Owner, first confirm whether subsequent searches and service processes will be affected.

{% hint style="warning" %}
Owners affect the ownership and query context of multiple business data types. If the company has already accumulated a large amount of existing customer, ticket, or service data, it is recommended to confirm the current data relationships and actual operational processes before making major changes to the Owner structure.
{% endhint %}