The answer exists. Finding it is the job.
A new support ticket comes in. Before an agent can respond, they need to understand what the customer is asking, determine what type of issue it is, and figure out where the answer lives.
For common requests, that can mean searching the help center, checking product documentation, looking through previous tickets, or pulling up customer and account information in another system.
Then the agent still has to piece that information together and write the response.
Multiply those steps across hundreds or thousands of repetitive tickets, and a large portion of the Support team’s time goes toward finding and assembling answers that already exist.
The bottleneck isn’t always solving the problem. It’s getting the right answer in front of the agent quickly enough to act on it.
The play: Describe how you want support tickets handled. Ballet builds the workflow.
You don’t have to build the integrations or map every technical step yourself. Tell Ballet how you want common support tickets handled in plain English.
What you hand Ballet
When a new support ticket comes into Zendesk, categorize the request and determine what information is needed to answer it. Pull the relevant information from our help center and Confluence, check the customer’s account information in Salesforce, and use their previous support history where relevant. Draft a response for the agent and flag anything that needs additional investigation or judgment before sending.
Ballet takes it from there. It builds the integrations and workflow needed to work across the systems involved, bring together the relevant information, and execute the process you’ve defined.
Once the workflow is built, it runs as deterministic, reviewable code, with AI reasoning where judgment helps and human review where your team wants it.
You describe what needs to happen. Ballet builds the workflow to make it happen.
Here’s how the workflow runs
1. A new support ticket starts the workflow
A ticket arriving in a support platform such as Zendesk or Intercom starts the workflow.
2. Ballet categorizes the request
Ballet determines what type of request the customer is making based on the categories and logic your team defines.
That might include account questions, product how-tos, billing questions, configuration issues, or known troubleshooting requests.
The category determines what information the workflow needs and where Ballet should look for it.
3. Ballet finds the information needed to respond
The answer may be spread across several systems. An agent might need the original ticket and conversation history from Zendesk, a troubleshooting article from the help center, internal documentation from Confluence, and customer information from Salesforce.
Ballet builds the integrations needed to work across those systems as part of the workflow, generating custom API integrations on demand. Instead of requiring an agent to search each source individually, Ballet brings together the information relevant to the specific request.
Your team defines which sources Ballet should use and what information matters for each type of support request.
4. Ballet drafts the response
Ballet uses the information it finds to build a draft around the customer’s specific request.
The draft can include the answer, recommended steps, relevant instructions, and other information the agent needs to respond.
For common requests where the answer already exists, the agent starts with a draft instead of an empty reply box.
5. The agent reviews and responds
The agent reviews the draft, makes any necessary changes, and responds.
When something requires additional judgment, Ballet can surface it instead. For example:
Needs review: Customer-specific configuration could not be confirmed.
Needs review: Ticket may require escalation.
This keeps the agent involved where their judgment matters without requiring them to manually research and assemble every response.
From incoming ticket to ready-to-review reply
Spend less time searching. More time helping customers.
When common tickets arrive with the relevant information and a draft response already assembled, agents can spend less time searching across systems and writing repetitive replies from scratch.
Straightforward requests can move through the queue faster, while agents focus on exceptions, complex issues, and conversations that require human judgment.
Because Ballet runs the workflow as deterministic, reviewable code, your team also has visibility into how the process executes.
Take this play and make it yours
Every Support team handles common requests differently. Before you bring yours to Ballet, answer a few questions:
- Which support requests are repetitive enough for this workflow?
- How should incoming tickets be categorized?
- Where do agents currently go to find the answers?
- What customer information might be needed to respond?
- When should an agent step in for additional review or investigation?
- What should happen when there isn’t enough information to confidently draft a response?
You don’t need to map out the integrations or design the technical workflow. Start with how you want a common support request handled and what your agent needs to confidently respond.
