DuckyHelper works in the apps a support team already uses, by seeing and using them the way a person at the computer would. In this example, a support lead hands it the morning refund queue: it reads each ticket, checks the policy and the order, and drafts the replies, then waits for an OK before anything goes out.
The queue is mostly read, look up and check
Most refund tickets follow the same path: read the ticket, find the order, check it against the policy, write the reply. Each one takes a few minutes. A morning of them is the whole morning, and the tickets that actually need a careful human answer wait behind the easy ones.
The work lives in three or four windows at once, the help desk, the store admin and the policy doc, and the rules are written for people to read, not for a script to parse. A reply that gets the policy wrong is worse than a slow reply, so nobody wanted a tool that answers customers on its own.
It works in the same windows the team does
The lead drags the orb onto Zendesk and says what to do. DuckyHelper opens the tickets, reads the policy in Notion and looks up each order in Shopify with its own cursor, while the lead keeps using theirs.
It's built not to send a reply on its own. It drafts each one and shows a Send, Edit or Deny card, so a person approves each message before it goes to a customer. Agent features like this are in early access.
Drafts ready, with a person on every send
Instead of starting from a blank reply, the team starts from a drafted one that already names the order and the right part of the policy, and spends its time on the tickets that need judgment.
Where an order falls outside the policy, DuckyHelper says so and leaves that ticket for a person. This is an example of how it works, not a measured result.
