Keep your helpdesk.We plug in. You migrate nothing.
Your team keeps working where it works. Pronomy reads tickets from your helpdesk and acts in your billing, store and CRM through their APIs. We're native with two tools and honest about the rest.
Native: Zendesk and Slack. Everything else connects via webhook, REST API or MCP. Names are trademarks of their owners.
Webhook. API. MCP.Pick whatever your stack already speaks.
No custom connector to wait for. If your tool can send an event, take an API call or run an MCP server, the agent can work with it.
Your helpdesk sends us an event when a ticket arrives or changes. We run the flow and answer back through your helpdesk's API.
Best for: getting tickets in from any helpdesk or form.
// example payload, illustrative { "event": "ticket.created", "ticket_id": "48213", "channel": "email", "customer": { "email": "jane@example.com" }, "message": "I cancelled and still got charged." }
You describe the endpoints the agent may call: refund, cancel, change plan, update an order. Each one gets its own permission and autonomy level.
Best for: taking real actions in billing, commerce and your own backend.
# action definition, illustrative name: refund_charge method: POST url: https://billing.example.com/refunds input: charge_id, amount success: status == "succeeded" autonomy: 4 up to $50, 3 above
If a system already runs an MCP server, point Pronomy at it. Its tools show up as actions, and you allow or block each one.
Best for: internal tools and anything that already has an MCP server.
// generic MCP config, illustrative { "mcpServers": { "orders": { "url": "https://mcp.example.com/orders", "headers": { "Authorization": "Bearer <token>" } } } }
Snippets are illustrative, not our API reference. Field names and URLs are examples. We share the real setup details during onboarding.
Two native. The rest through open doors.We'd rather tell you that than fake a logo wall.
"Native" means we built and use a dedicated integration. "Via API / webhook / MCP" means we connect through the system's own API, a webhook or MCP. It works, and setup is a bit more hands-on.
Helpdesks where tickets live
Billing & commerce where actions happen
Knowledge what the agent reads
Chat & internal where your team talks
Not on the list? Probably still fine.
If it has an API, can send a webhook or runs an MCP server, we can most likely connect it. Ask us on a call, or email us the name, and we'll tell you straight.
If it can send a webhook, we can probably talk to it. If it's a fax machine, we need to have a different conversation.
Product names are trademarks of their owners. Listing a system means we can connect to it through its own interfaces. It does not mean a partnership or endorsement.
It reads what your team reads.And it tells you where the docs are thin.
Answers come from your sources, not from the open internet. When a question has no good source, the agent says so and hands off. It would rather fetch a person than invent a refund policy. With Analytics, those gaps become a list of docs to write.
- Website URLsHelp center, FAQ, pricing and policy pages
- Static documentsPolicies, playbooks and internal guides you upload
- Predefined responsesYour macros and approved wording, used as-is when required
- Past conversationsHow your best agents actually solved it
- Notion · ConfluenceInternal wikis where the real rules live
- Google DriveDocs and sheets your team keeps up to date
- MongoDBStructured product data, such as plans and feature flags
No helpdesk yet?Put the agent on your site.
Add Pronomy as a chat widget on your website. Same flows, same actions, same scorecards. When a conversation needs a person, it goes to your team (in Slack, for example) with the full story.
- Says it's an AI assistant, clearly, from the first message
- Replies in the customer's language
- A human is always one message away
Plugging in is fast.Getting your rules right is the real work.
Often that's all it takes to connect a helpdesk or an API. You can do it yourself, or we do it for you, free.
Takes longer. Here's why.
- Your policies live in people's heads. "We refund within 14 days" usually comes with five unwritten exceptions.
- Permissions are real decisions. Which refunds can the AI do alone? Which need a person? You decide that, not us.
- "Correct" needs a definition. Scorecards can only grade what you've written down.
- Trust is earned. Shadow mode first, then one live flow, then more.
So we don't hand you an empty form. We read your tickets, docs and policies and pre-fill a draft of your flows for you to confirm. Onboarding is free.
Connecting your systems is a big ask.Here's what we promise in return.
- NDA and DPA signed before we touch any data
- Your customer data is never used to train models
- Role-based access, human approval for risky actions, full audit log
- Not SOC 2 certified yet. We'll say so the day we are.
Integration questions.Answered without a sales deck.
Do we have to switch helpdesks?
What's the difference between "native" and "via API"?
Who does the technical setup?
Will this mess with the setup we already have?
Can the agent act in our own internal admin panel?
What happens if one of our systems is down?
Which channels do you cover?
If part of your stack is a webhook someone wrote years ago that nobody dares touch, you’re in good company. Tell me about it. I won’t judge, and I’ll tell you honestly whether we can plug in.