Convert a conversation into a ticket
Create tracked follow-up from a conversation, manage ticket state, and understand how reply actions interact with closure.
Use a ticket when work must continue beyond the live conversation or needs an explicit type, state, assignee, or resolution path. A ticket complements the conversation timeline; it should not duplicate every customer message or replace a necessary reply.
This guide explains when to create a ticket, how to capture actionable context, how the primary ticket appears in Inbox, and how send-and-close or state actions can affect both the ticket and handoff state.
How this fits into Humind
Inbox is the operational record of customer conversations. It combines message history, shopper and product context, internal collaboration, human-handoff state, tags, and tickets. Customer replies and internal notes have deliberately different visibility.
A consistent team routine matters more than any individual filter. Agree when to take over, when to leave an internal note, when to create a ticket, and when to return a conversation to the AI so ownership remains clear to every operator.
Before you start
Access: Inbox access is required to work from a conversation. Ticket read or write actions follow the company's ticketing permissions and configuration; provider settings are administrator-controlled.
- Confirm ticketing is enabled and the intended ticket type and statuses exist.
- Read the conversation, internal notes, tags, and existing primary ticket.
- Know whether the team uses Humind ticketing or a tested external provider.
Step-by-step workflow
Decide whether a ticket is needed
Create a ticket for work that needs tracked follow-up, another team, a structured lifecycle, or resolution after the shopper leaves. Keep a simple question in the conversation when the operator can answer and complete it immediately.
Check for an existing primary customer ticket first. Multiple tickets for one issue create unclear status and ownership.
Create actionable ticket context
Use the conversation's ticket action and choose the relevant type or initial state offered by the company's configuration. Summarize the request, verified facts, work already done, customer expectation, and next action.
Link or rely on the conversation context rather than copying unnecessary personal data into free text. Use internal notes for teammate reasoning that does not belong in a ticket field.
Maintain status and ownership
Review the primary ticket in the conversation details. Update properties as the investigation changes and use the company's status categories consistently. Humind maps configured statuses to categories such as resolved for the send workflow.
A ticket left open with no owner or next action is not a reliable handoff. Use mentions or the team's assignment process when another person must act.
Reply and close intentionally
When a primary ticket exists, the reply send menu can show a send-and-close action. That action sends the customer reply, moves the ticket to the configured resolved-category status, and returns the conversation to AI. Other send-menu actions can update a ticket state.
Read the current menu label and status before clicking. Closing the ticket and handing back to AI are related but distinct outcomes that happen together in this path.
Verify the customer and operator result
Confirm the shopper received the intended message, the ticket shows the correct state, the thread ownership is correct, and internal notes remain private. Reopen or update the ticket according to policy if new information arrives.
For external providers, verify the corresponding record in the provider during initial rollout. Do not assume a credential toggle guarantees end-to-end ticket synchronization.
Permissions and important caveats
- Ticket types and status names are company configuration; use the current labels shown in the workspace.
- Send-and-close can change both ticket and conversation state in one action.
- External Gorgias or Zendesk behavior must be separately configured and tested.
- A ticket is internal operational work and does not by itself notify the shopper of progress.
Verify the result
Use this checklist before considering the work complete:
- The ticket represents a real follow-up need and does not duplicate an existing primary ticket.
- Summary, type, state, owner, and next action are understandable to another teammate.
- The final customer reply, ticket status, and AI or human ownership match the intended outcome.
- External provider records are verified when that provider is part of the workflow.
Troubleshooting
Ticket actions are unavailable
Confirm ticketing is enabled, the company has ticket types and statuses, and your role has the required access. Ask an administrator to review the provider and Inbox configuration.
Send-and-close used the wrong status
Review which configured status is mapped to the resolved category. Correct the ticket state and ask an administrator to fix the status configuration before operators use the combined action again.
An external provider did not receive the ticket
Check the selected provider, administrator credentials, company context, and the provider's own record. Treat the integration as unverified until a full test succeeds.