> For the complete documentation index, see [llms.txt](https://features.scnd.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://features.scnd.com/v2.0/core-concepts/account-claiming.md).
# Account claiming
Allows operators to pre-create vendor accounts that vendors can later take ownership of
* [Why](#id-1.14.x-recaptchabundle-businessrules-why)
* [Which context](#id-1.14.x-recaptchabundle-businessrules-whichcontext)
* [Interfaces](#id-1.14.x-recaptchabundle-businessrules-interfaces)
* [Configurations](#id-1.14.x-recaptchabundle-businessrules-configurations)
* [Workflows](#id-1.14.x-recaptchabundle-businessrules-workflows)
* [Special rules](#id-1.14.x-recaptchabundle-businessrules-workflows)
## Why
When a marketplace is launched, it has no vendors and no listings. Askers who land on an empty platform leave, and vendors have no incentive to register on a platform with no demand.
Account claiming breaks that deadlock. Operators create vendor accounts and listings on behalf of real vendors, so the platform looks and behaves as a live marketplace from day one. Each of these accounts is flagged as *claimable*: the vendor it belongs to can later take full ownership of it — set his own login email and password — without the operator having to transfer anything manually.
The invitation to claim is sent at the moment it carries the most value for the vendor: when an asker sends him a booking or quote request, or when an RFP matching his profile is published.
## Which context
Platforms in a bootstrap or market-launch phase, where supply must be visible before demand exists.
Typically B2B or B2C marketplaces on which the operator already knows his target vendors (existing commercial relationships, professional directories, imported databases) but cannot expect them to register on their own before the platform generates activity.
The feature is also relevant for platforms migrating from an offline or legacy system, where the vendor base already exists and must be re-onboarded progressively.
## Interfaces
You can find here all interface documentation related to the Account claiming feature.
**SBO:**
* [Importing claimable users](/v2.0/superadmin/users/importing-claimable-users.md)
* [Account claiming management](/v2.0/superadmin/users/account-claiming-management.md)
**Front:**
* [Claim a user account](/v2.0/front-office/claim-a-user-account.md)
## Configurations
The feature is configured in SBO > Configuration > Features > **Claimable offerors**.
| Setting | Description |
| ---------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Account claiming enabled | Whether the account claiming feature is enabled or not. |
| Notify the commercial mailbox for unclaimed accounts | Sends the platform notifications addressed to an account nobody has claimed yet — booking request, quote, call for tenders — to the commercial mailbox defined in Platform Configuration. The claim invitation itself is never concerned: it goes to the vendor's contact address. |
| Stalled import timeout | How long a claimable vendor import may go without progress before it is considered interrupted and marked as failed. |
| Claimable vendor import retention | How long finished imports are kept before automatic deletion. This is disposable processing state, not a browsable history. |
One additional setting is located in SBO > Configuration > Features > **Platform Configuration**.
| Setting | Description |
| ---------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| Email sales team | Address that receives, on the vendor's behalf, the platform notifications an unclaimed account would normally get — booking request received, quote request, listing published, and so on. It is not a claim contact address and is never used to send the claim invitation. |
When the feature is disabled, the import screen, the claiming section of the user detailed view and the front-office claiming pages are no longer available.
Claim links are valid for 7 days from the moment they are sent.
## Workflows
#### Account lifecycle
A claimable account goes through four states, displayed as the *claim status* in the back office:
| Status | Meaning |
| ------------------ | --------------------------------------------------------------------------------------------------------- |
| Pending (no email) | The account is claimable but has no claim contact email. No invitation can be sent until one is provided. |
| Pending | The account is claimable, no claim link has been sent yet. |
| Link sent | A claim link has been sent to the claim contact email. |
| Claimed | The vendor has completed the claiming process and owns the account. |
| Deletion requested | The vendor declined and asked for his account to be deleted. |
#### Where the emails go
Two distinct flows of email coexist for a claimable account. They have different purposes, different recipients, and neither can replace the other.
The **claim invitation** is sent to the claim contact email declared on the account — the address of the real vendor the operator wants to onboard. It is the only email the vendor receives before he owns the account, and the commercial mailbox is never used for it.
The **platform notifications** are the standard transactional emails any vendor receives during the life of his account: a booking request has come in, a quote has been requested, a listing has been published, an RFP matches his profile. As long as the account is unclaimed, the vendor is not the one reading them. Enabling "Notify the commercial mailbox for unclaimed accounts" routes them to the sales team address, so the operator sees the activity generated by the account and can follow up commercially in the vendor's stead. Once the account is claimed, they go to the vendor's own address.
Once the account is claimed, this redirection stops: notifications go to the vendor's own login email, as for any other vendor account.
#### Sending the claim invitation
Two mechanisms send the invitation.
Manual: the operator clicks "Send the claim link" from the user detailed view. This is available as long as the account has not been claimed yet.
Automatic: the platform sends the invitation on its own when an event gives the vendor a reason to join. Two events are handled:
* an asker submits a booking or a quote request on a listing owned by a claimable account;
* an RFP is published and the claimable account qualifies to answer it.
In both cases the email includes a summary of the triggering event, so the vendor knows what he is being invited for.
The automatic mechanism only applies to accounts whose claim status is *Pending*. If the status is already *Link sent*, *Claimed* or *Deletion requested*, no further invitation is sent to the vendor.
If the claimable account has no claim contact email, its claim status is *Pending (no email)* and no invitation can be sent. The operator is notified instead, and asked to reach out to the vendor manually. The status only moves to *Pending* once a contact email is saved on the account.
#### Claiming the account
The vendor clicks the call to action in the email and lands on the claiming page. He sets his login email and his password, accepts the terms and conditions and the privacy policy, and confirms. He is then logged in automatically and redirected to his vendor dashboard. The claim status switches to *Claimed* and a confirmation email is sent to his new login email.
From that moment on, the account behaves as any other vendor account: notifications are sent to the vendor's own address and are no longer redirected to the commercial mailbox.
#### Declining the claim
From the email or from the claiming page, the vendor can state that he does not want to join the platform and request the deletion of the account created for him. The claim status switches to *Deletion requested* and the operator is notified. The actual deletion remains a manual operation carried out by the operator from the user detailed view.
## Special rules
* Only accounts created by an operator can be made claimable. Accounts registered by users themselves through the front office cannot.
* Only one claim link is active per account at a time: sending a new link invalidates the previous one.
* A claim link is single-use. It is invalidated as soon as the account is claimed, as soon as a deletion is requested, or when it expires.
* Once an account is *Claimed*, its claiming settings become read only and the account can never be claimed again.
* A claimable account has no password until it is claimed, and therefore cannot be logged into.
* Imports are not kept as a history: once the retention delay has passed, the processing state of a finished import is deleted.
---
# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.
## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation by asking a question.
Perform an HTTP GET request on the following URL with the `ask` and `goal` query parameters:
```
GET https://features.scnd.com/v2.0/core-concepts/account-claiming.md?ask=&goal=
```
`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is what the user is ultimately trying to achieve, the reason they need the answer. Sharing it helps GitBook give you a better, more relevant answer. A goal is most helpful when it describes the outcome the user wants rather than restating the question. For example, with `ask=how do I create an API token`, a goal like `automate deployments from our CI pipeline` lets GitBook tailor the answer to that use case.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.
Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.