Migrate from Mekari Qontak to Twenty CRM

Qontak Contacts map directly to Twenty People. The primary fields (name, phone, email, address) migrate 1:1. We preserve the Qontak contact source channel (WhatsApp, Instagram, Email, LINE) as a custom field on People since Twenty has no native channel attribution model. Custom Contact properties migrate to Twenty custom fields, which must be pre-created in Settings before import. Phone numbers in Qontak's Indonesian format (08xx) require normalization to international format (62xx) during the transform step.

Qontak Companies map to Twenty Companies with domain and address fields preserved. The company domain becomes the Website field and is used as a dedupe key. If Qontak stores multiple contacts per company with a primary-company assignment, we resolve the Company record first so that the Company-People relationship is satisfied at import time.

Qontak Deals map to Twenty Opportunities. The Qontak dealstage property (enumerated stage names that vary by plan tier) maps to Twenty Opportunity stage values, which we configure in Twenty's workspace settings before import. Deal amount, close date, and owner assignment migrate directly. Qontak's pipeline-to-stage hierarchy requires pre-configuration in Twenty's pipeline settings to match the source pipeline structure.

Qontak's enumerated stage lists (which differ by Sales Suite, Service Suite, and Qontak 360 tiers) map to Twenty workspace-configurable stage values. We extract the complete stage list during discovery, configure the matching stage set in Twenty before any Opportunity import, and map stage probabilities from Qontak to Twenty stage settings.

Qontak Tickets migrate to Twenty Cases if the customer uses a service-oriented workflow, or to a custom object (e.g., SupportTicket) if Twenty's native Case object does not cover the ticket schema. Qontak ticket status values (enumerated) map to Twenty status picklist values that we configure before import. Custom ticket fields migrate to Twenty custom fields pre-created in Settings.

Qontak agent records (Supervisor, Agent roles, channel allocation rules) map to Twenty People records with the role stored as a custom text or select field. We resolve agent email matches against Twenty user accounts. If a Qontak agent has no corresponding Twenty user, we hold the mapping in a reconciliation queue for admin provisioning before record import.

Qontak custom Contact properties (accessible via Mekari API) migrate to Twenty custom fields on the People object. We extract the full custom property schema during discovery, pre-create all custom fields in Twenty's Settings with matching field types, and map property values during the transform step. Qontak multi-select or checkbox properties convert to Twenty multi-select picklist fields.

Qontak custom Deal properties migrate to Twenty custom fields on the Opportunity object. Same pre-creation requirement applies: Twenty requires fields to exist before import. Custom Deal fields referencing other Qontak objects (e.g., a custom field pointing to a related Contact) map to Twenty lookup fields on Opportunity after the target object is imported.

Qontak chatbot flows use an internal JSON schema that is not portable to Twenty or any other CRM platform. We extract the full decision tree structure, conditional branching logic, and message templates from Qontak's flow builder and document them as a re-build guide. The flow map includes trigger conditions, decision node branches, delay actions, and CRM action steps. No automated import is possible.

Qontak automation rules (trigger conditions, action sequences, scheduled broadcasts) use a Qontak-specific workflow schema that does not export in a portable format. We document every active automation: trigger type, conditions, action sequence, and scheduling. Twenty's automation model requires manual rebuild; the inventory document maps each Qontak automation to a recommended Twenty equivalent or a third-party automation tool (e.g., n8n, Make) if the workflow involves external system actions.

Qontak list membership and segmentation criteria are stored as separate objects. We export list definitions and populate list membership as a multi-select custom field on People (e.g., segment_1, segment_2). Dynamic segment membership, which recalculates based on current contact data, does not migrate as a live rule; we deliver a static snapshot and a re-build recommendation for Twenty's filtering or a third-party segmentation tool.