/
Contacts

Contacts

Owned by Spyroulla Ioakim, created
Last updated: Feb 07, 2025
22 min read

Contacts represent an organisation's customers and can either be physical Persons or Companies. They serve as the focal point within CRM.COM and initiate most business processes. 

There are several ways to create Contacts in CRM.COM:

  • Via an external integration system using BackOffice APIs

  • Through a Contact registration flow, using either the CRM.COM consumer app or portal

  • Through your own front-end applications using Self-Service APIs

  • Manually, by a system user through the CRM.COM back-end system

  • Through an import utility, by providing the data file from an external system (see Platform> Import Data)

THE ESSENTIALS

Before taking a more detailed look at Contacts, let's get familiar with some key terms used throughout CRM.COM regarding Contacts.

An example of the type of information that can be logged for a contact includes their name, surname, email, phone number, one or more addresses, preferred language, date of birth, and more.

On the financial side of things, each contact owns a CRM.COM Wallet, an account, and multiple payment methods that can be viewed and managed from front-end applications. A contact can be uniquely identified using their CRM.COM Wallet code, but various other identification methods are also available.

Contact Identity

This is the contact authentication and identification credentials. Their registration, identification and authentication processes can be carried out via front-end applications using the CRM.COM self-service APIs, with the authentication method chosen by the business through the back-end system.

Types

A Contact can be of type Person or Company. Person type Contacts are physical persons, whereas Company type contacts are commercial businesses. The type is set upon Contact creation and cannot be changed after that.

Person type contact
Company type contact

Contact Code

This is the CRM.COM code which, again, uniquely identifies a Contact. It can be set manually during contact creation or automatically generated by the system. Once set, the Contact code cannot be changed.

Birthday

A Contact's birthday can be set, therefore allowing the business to communicate with the Contact to wish them many happy returns or even offer them the opportunity to take advantage of a Reward Offer on their special day.

A Contact's birthday can be set:

  • By the Contact using a consumer mobile app/portal (using a self-service API)

  • By a user through the back-end system

Name Day

A name day is a day of celebration that is typically associated with one's Christian name. Name days can be utilised in Reward Offer configurations to award contacts on their special day. A prepared list of Christian Orthodox name days can be imported into http://CRM.COM for this purpose.

A Contact's name day can be set:

  • By the Contact using a consumer mobile app/portal (using a self-service API)

  • By a user through the back-end system

Language

CRM.COM is a multilingual system, the default language setting is English, but other languages can also be enabled via the system settings. 

The Contact's selected language is used in customer-facing apps/portals, but also for communications sent to the Contact, and can be changed:

  • By the Contact themselves using a consumer mobile app/portal (through a self-service API)

  • By a user through the back-end system

Country of Agreement

If your business operates on a multi-regional level, you can configure multiple supported Countries of Agreement, thus easily distinguishing the pricing and taxation policies for your product offerings in different countries.

During the contact registration procedure, contacts are prompted to select their Country of Agreement (typically the country they reside in). When placing an order, a Contact will see prices and taxes based on their selected Country of Agreement.

Sales Model

Pricing policies are applied based on Sales Models as well, which is one of the key conditions. There are two default sales models: Wholesale, which is by default assigned when creating a Contact of type Company, and Retail, which is assigned to Contacts of type Person. Additional Sales Models can be configured and assigned to Contacts, denoting the prices that will be applied when contacts place orders or are billed for services.

Loyalty Identifiers

Typically a loyalty identifier is a Contact loyalty number in an external system. If Contacts are imported to CRM.COM, the respective loyalty identifier (if available) can be set for each Contact. 

Loyalty identifiers are also used in front-end registration processes (app, portal) to create authentication credentials for an existing Contact in the system. 

Loyalty identifiers can also be manually added to Contacts via the CRM.COM back-end system. Refer to the Rewards section in this manual for further details.

Interaction State

This state reflects the Contact's engagement with the Business. It's determined by the timing of the Contact’s last financial transaction, i.e. invoice, payment, refund, payout, credit note, top-up, or transfer:

  • Never Engaged - No financial transactions have ever been performed

  • Engaged - A financial transaction was performed within the last 60 days

  • Dormant - A financial transaction took place between 61-120 days ago

  • Resting - A financial transaction was performed more than 120 days ago

When Contacts are first created, they automatically assume a state of Never Engaged. They only become Engaged once a financial transaction takes place for that Contact.

Identity Verification

This state indicates whether CRM.COM has verified the Contact's identity. Verification is performed via an activation link or an OTP sent to the Contact in a communication during the registration process.

If a Contact's identity has not been verified, there are no restrictions to the type of actions that can be performed on behalf of the Contact via the back-end system. However, it's possible for front-end applications to force a contact to verify their email (using the email/password registration option) to access the app/portal, refer to the Contact Authentication & Identities settings for further details.

Referral Code

When a Contact is created in http://CRM.COM , it is assigned a unique 6-character alphanumeric referral code. This code can be set via the self-service API when creating the Contact, or alternatively, it can be auto-generated by the system. 

The referral code is used during a referred Contact's registration and can result in the referring Contact receiving an award subject to the Referral Reward Offer configuration. 

Marketing Settings

Contacts can specify whether they want to receive marketing-related material via email or SMS from the business; these settings can be changed at any point in time. Contacts can opt-in or opt-out from receiving such communications via:

  • The consumer mobile app/portal (using a self-service API)

  • The back-end system - manually changed by a system user

  • Links in a communication sent to the Contact

Note that the Business can override (i.e. ignore) the marketing communication settings for critical communications when configuring a Communication Plan for mandatory system communications, such as a verification communication sent during the Contact registration process.

CIMs

A Customer Identification Medium (CIM) is an attribute that uniquely identifies a contact when interacting with CRM.COM. CIMs are particularly useful when processing Purchase Events, and can be used to identify the contact responsible for the transaction.

CIMs are c