Three pillars to configure before go-live, organized from open notes, the August 26 and September 2 check-ins, and recent email threads with Nilesh. Check items off as they close.
Unicity could not secure the licensing needed for Freshdesk. Going forward, they will deploy RingCentral in Europe and continue using RingCentral in the Americas. This replaces the earlier Zendesk/Freshdesk plan — Fin now needs to integrate with RingCentral instead. RingCentral has no native connection to Intercom, so this requires custom API/webhook development (est. up to one week including testing).
Fin's knowledge source is not RingCentral or a legacy helpdesk — it's Unicity's own content library ("Unicity Brain"), hosted in Google Drive, owned by Lawrence. RingCentral only holds historical tickets/conversations, which is not what Phase 1 needs. Access to the Drive has been requested but not granted yet — Matias and Laura are still waiting.
Nilesh requested a visual flow diagram (data flow / architecture overview) to help Mark and the executive team understand how the integration works end-to-end. Delivered.
RingCentral has no native connector to Intercom — this requires custom API/webhook development. Estimated up to one week including testing.
Maintaining separate knowledge bases per country isn't sustainable at Unicity's scale (50+ countries). He proposed exploring a centralized RAG-based approach with country-aware retrieval.
Laura's answer: Fin already works this way — it's RAG by design, retrieving from indexed content rather than answering from memory. Intercom supports multiple Help Centers per workspace if content needs to be physically split by region, but the real control mechanism is Audiences: rules based on customer attributes (like country) that determine which content Fin actually pulls from for a given customer. Articles get tagged by region, and Fin only surfaces the ones that match.
Untagged content is visible to everyone by default — tagging needs to be deliberate as the KB gets built out, or content meant for one country could leak into answers for another.
This is fully independent of Freshdesk/RingCentral/Articles — it can proceed right now.
Email is the primary identifier and must be unique per contact. Duplicate emails exist in the historical customer base from discontinued past practices — needs clean-up before sync. Intercom does not group/merge users on the fly: a contact who first emails and later messages on WhatsApp will be created as two separate profiles unless both channels are already loaded against the same record.
Not needed for the initial import. These come in once subscription/order lookups go live, pulled live via Unicity's customer search API rather than bulk-loaded.
To avoid duplicate profiles, all ~7 million contacts need to be loaded into Intercom upfront (email + phone minimum, name if available) via the Intercom API (POST /contacts), before go-live. Confirmed approach: initial load via CSV. After that, since Unicity's customer database changes daily, updates need to sync automatically — Nilesh asked whether their existing Kinesis event stream could be used instead of a webhook.
Intercom doesn't consume Kinesis (or any event bus) directly — it only exposes a REST API. Kinesis can replace the webhook as the trigger for updates, but Unicity still needs a small consumer on their side (e.g. a Lambda) that reads the stream and calls Intercom's API per change.
Compliance concern about exporting a full data dump of ~7M customer records to Intercom. This needs sign-off before the bulk import can run.
If a contact reaches out on a channel where they're not yet recognized, Intercom creates them as a lead. If the identifying info (e.g. phone number) matches an existing user, Intercom flags a possible duplicate and lets you merge them manually with one click. This is why loading contacts upfront matters — it minimizes leads floating around as unmerged duplicates.
Workspace owners set (Matthew, Nilesh, Zach). WhatsApp still blocked on legal entity definition. Email channel connection pending, but DNS setup can proceed in parallel.
Automations outside of Fin: e.g. if a message comes from a specific address, auto-tag, assign to a specific inbox, or set a specific SLA — logic that ran in Zendesk and needs to be replicated.
Ticket types and internal logic: not about the 100+ granular reasons customers write in, but the higher-level category split.
Note: the detailed use cases (order status, subscription updates, etc.) were already shared and mostly require API calls — that part is covered. This is specifically about the category/ticket-type structure.
Without these, structure (inboxes, roles, permissions) can still be configured, but the real customer → Fin → resolution/escalation flow can't be validated.
Phases 1–3 focus on Europe only. Voice is the last phase, scoped to the U.S.
| # | Action | Pillar | Owner |
|---|---|---|---|
| 1 | Get Google Drive KB access granted to Matias & Laura | Knowledge Base | Unicity (Grace/Fenton) |
| 2 | Authenticate unicity.com domain in Intercom, then set up support@ forwarding | Knowledge Base | Unicity IT (John/Logan) |
| 3 | Share RingCentral API docs/endpoints | Knowledge Base | Nilesh |
| 4 | Build RingCentral–Intercom integration (API/webhooks) | Knowledge Base | EscalateOps (depends on 3) |
| 5 | Consult Zach/Compliance on the initial customer data import | Contacts | Nilesh |
| 6 | Create Intercom attributes and run the initial bulk import | Contacts | EscalateOps + Unicity (depends on 5) |
| 7 | Review Zendesk automations/ticket types and send to Matias | Workflows | Nilesh |
| 8 | Build and share architecture/data-flow diagram for execs | Knowledge Base | EscalateOps |
| 9 | Finalize and share this MVP plan in Slack for team feedback | — | EscalateOps |
Every API step referenced across the three pillars, in one place, so nobody has to remember where to click or what to send.
support@unicity.com) — Intercom will show it as unauthenticatedRun this once per attribute (e.g. whatsapp_number, later unicity_customer_id, region, subscription_status) before importing any contacts, so the import matches without errors.
curl -i -X POST \ https://api.intercom.io/data_attributes \ -H 'Authorization: Bearer <INTERCOM_TOKEN>' \ -H 'Content-Type: application/json' \ -H 'Intercom-Version: 2.16' \ -d '{ "name": "whatsapp_number", "model": "contact", "data_type": "string" }'
Only email is strictly required. Send phone and name whenever available — phone is what lets an email conversation and a WhatsApp conversation resolve to the same profile. This call runs once per contact for the ~7M-record initial load (batched, respecting rate limits), and again for any new/changed contact on the nightly sync.
curl -i -X POST \ https://api.intercom.io/contacts \ -H 'Authorization: Bearer <INTERCOM_TOKEN>' \ -H 'Content-Type: application/json' \ -H 'Intercom-Version: 2.16' \ -d '{ "email": "member@example.com", "phone": "+34600000000", "name": "Jane Doe" }'
A repeat call with an email already in Intercom returns 409 Conflict — use GET /contacts or the search endpoint to fetch the existing contact and PUT /contacts/{id} to update it instead of re-creating it.
Not an Intercom endpoint — Intercom only exposes a REST API, it doesn't consume Kinesis or any event bus directly. Kinesis can be the trigger, but Unicity still needs a consumer on their side (e.g. a Lambda) that reads the stream and calls the same POST /contacts / PUT /contacts/{id} endpoints above whenever a record changes.
Nilesh confirmed Unicity doesn't currently have RingCentral/Fin-related API docs on hand. Once shared, this block gets filled in with the actual endpoints (likely call/voice event webhooks + a way to post Fin's response back into the call/message flow) and the Intercom-side webhook that receives them.
September 15th target reaffirmed but flagged as at-risk given the current pace of blockers — tighter, more frequent communication was agreed as the mitigation. New recurring cadence: Tuesdays = technical session, Thursdays = business session. A short agenda/action brief will go out before each meeting so time isn't spent re-explaining context.