Open a Zendesk onboarding ticket for each new Polar customer
A Polar + Zendesk agent flow
Someone buys through Polar and your support team has no idea a new customer exists until that customer writes in confused. Flip the order: open the onboarding ticket the moment they purchase. The agent lists customers with polar_customers_list, reads the ones created since the last run, and opens a Zendesk ticket per new customer with create_ticket, the customer's email and a welcome checklist sitting in the ticket body for an agent to work. Polar answers the list request rather than pushing, so the agent runs on a cadence, every few minutes, and a customer it has already onboarded, matched by Polar id, doesn't get a second ticket. Support reaches out first instead of reacting last.
The flow
polar_customers_listLists customers.
create_ticketCreate a new Zendesk ticket.
Step by step
- List new customers
The agent calls polar_customers_list newest-first and reads down until it hits a Polar customer id it has already processed. Each entry carries the customer id, email, and name.
- Skip the already-onboarded
It tracks the Polar customer ids it has opened tickets for, so a customer who lingers across runs isn't ticketed twice. This Zendesk server has no search tool, so the dedupe lives in the agent's own state, not a Zendesk lookup.
- Open the onboarding ticket
create_ticket files a ticket with a subject like New customer onboarding and a body holding the customer's email, the welcome steps, and the Polar customer id for traceability.
Tell your agent
Every five minutes, list Polar customers created since the last run, and for each new one open a Zendesk ticket titled 'Onboard <name>' with the customer's email and our welcome checklist in the body. Put the Polar customer id in the body and skip customers already onboarded.
Setup
This flow needs both servers connected to your agent. Follow each install guide:
Worth knowing
- polar_customers_list returns the customer record; it doesn't tell you what they bought. If the ticket should mention the product or plan, the agent reads polar_orders_list or polar_customers_get_state as a second call and joins on the customer id.
- create_ticket sets the requester by a numeric Zendesk user id, not an email, and this server exposes no user-lookup or search tool. Put the customer's email in the ticket body rather than as the requester, or pre-create the Zendesk user out of band and pass its id.
- Carry the Polar customer id with each ticket (in the body, and in a tag if create_ticket exposes a tags field) and dedupe on it in the agent's own state. Email alone is shaky, since the same person can buy twice or change addresses; and with no Zendesk search tool the agent can't query back for an existing ticket, so the id has to live in the state it keeps between runs.
Questions
- Why a support ticket and not a CRM record?
- A ticket gives the new customer an owner, a status, and a place to track the onboarding conversation, which a CRM contact alone doesn't. If you also want a CRM record, that's a separate write to your CRM of choice in the same run.
- Can it assign the ticket to a specific agent or group?
- Yes. create_ticket accepts assignee and group fields, so the agent can route onboarding tickets to your success queue, optionally branching by the customer's plan or region read from Polar.