Automate Intercom work with your agents

Trigger: A customer opens a conversation in Intercom, and no teammate is assigned to it.

With Maplith:

1. Signals: With Maplith’s Intercom integration (rolling out), the conversation arrives as a support_case_opened signal. Until it reaches your workspace, your agent looks for new conversations in Intercom with its own read access.
2. Task context: get_task_context on the case returns the playbook “Work a new Intercom support case”, if you put it in use, and what the agent’s key may do.
3. Route: route from the conversation to its contact by contact id, then to the same person in your shop or billing system by email or by the external user id.
4. The action gate: request_action for a task for whoever assigns the inbox: the case, the customer found in your shop or billing system, and the team the playbook names. A person assigns it in Intercom.
5. Record and value: record_action records who took the case and how it ended.

Result: Whoever assigns the inbox gets the case with the customer already found in your other systems.

Trigger: A customer raises a ticket about a delivery, and the order number sits in one of the ticket’s attributes.

With Maplith:

1. The map: get_object on the tickets says whether your ticket type keeps an order number in an attribute, and which one.
2. Route: route from the ticket to the order in your shop by that order number, with how far Maplith trusts the hop.
3. Findings: Where a scan found tickets whose order number matches no order, a finding says so, with its evidence and a recommendation.
4. The action gate: The agent drafts a reply from the order’s fulfillment status, which it read in the shop with its own access, and request_action decides whether a person approves the reply. Maplith never sends it: your agent does, only with write access you give it in Intercom separately (its Write conversations permission), once approved.
5. Record and value: record_action records the reply and closes the loop on the ticket.

Result: The customer gets the delivery status from the order, not a request to repeat the order number.

Trigger: Billing asks which Intercom contact belongs to a paying customer, and finds a lead and a user with the same email.

With Maplith:

1. Ask: ask: “how do Intercom’s contacts tie to our billing customers?” The answer cites its joins: by email, or by the external user id your product sends.
2. Route: route from the Intercom contact to the Stripe customer by email, with how much Maplith trusts that hop.
3. The map: get_object on the contacts says which of the two carries the external user id; the agent reads both contacts in Intercom with its own read access.
4. The action gate: request_action for a task for the person who looks after Intercom’s contacts, with both contacts and the id that should decide between them.
5. Record and value: record_action records the task and which contact was kept.

Result: Billing and support talk about the same person, keyed by the id your product sends.