Appmint Tickets and Resolution

▶ Play video

Watch on YouTube ↗

Video chapters

1. 0:00 Welcome
2. 0:09 Overview: the life of a ticket
3. 0:48 Part 1 · Log a ticket — Find Tickets in the menu
4. 1:02 What a ticket holds: explained
5. 1:24 Log Nina's call
6. 2:29 Part 2 · Notes and replies — Notes and replies: explained
7. 2:47 A note, a reply, and Nina's answer
8. 3:43 Part 3 · Take it and hand it on — Who has it: explained
9. 4:02 Take it, then hand it to Jordan
10. 4:36 Part 4 · When the clock runs out — When the clock runs out: explained
11. 4:58 Escalate the overdue ticket
12. 5:54 Part 5 · Resolve, find and reopen — Resolve, find and reopen: explained
13. 6:20 Resolve, find and reopen Nina's ticket
14. 7:44 Wrap-up

Written guide

Overview

This course covers Appmint CRM Support Tickets. We will create a ticket, give it the right customer and owner, use notes and messages appropriately, and manage its status through resolution. We will also inspect workflow participation so an ordinary status change is not confused with moving a ticket through a configured workflow.

01. Create a ticket with customer context

Why this matters

Tickets track support work, while Chat and Communications Center carry conversations. Keep the customer, source and issue on the ticket so another staff member can continue.

Follow these steps

Open CRM → Tickets → New Ticket. Enter the issue’s title and description, select the correct customer/source and set priority and relevant properties. Save and reopen the same ticket.

Check the result

The current screen is Support Tickets; the form exposes Details and Messages. Do not claim a ticket was emailed because it was saved.

02. Separate notes from customer replies

Why this matters

Internal notes retain investigation for staff. A customer-facing reply has an external destination and needs its own delivery check.

Follow these steps

Open the ticket and add the internal note through Add Note. Inspect its history. Open Messages for the customer conversation. The current reply composer is rendered only when the ticket is saved (sk exists) and Reported By Email is present. A phone-only ticket can therefore lack the composer even though SMS is a supported reply choice. Check and save the actual customer email when appropriate; do not invent one just to reveal a control. Choose the offered reply channel and configured sender, compose the reply, choose Send Reply, then verify the actual recipient receives it. Messages history alone does not prove external delivery.

Check the result

A note is not a reply. Recipient delivery, attachment access and public/internal visibility must be verified with independent identities.

03. Assign responsibility and move the work

Why this matters

Ownership and workflow stage make responsibility visible. A missing workflow is different from a ticket stuck in an existing stage.

Follow these steps

Assign the intended staff member and inspect the saved ticket properties. Open its workflow context, supply required inputs and move to the intended stage. Reopen and compare ownership, state and history.

Check the result

The current form explicitly explains when a ticket is not on a workflow. Do not invent stage controls for an unattached legacy ticket.

04. Resolve and reopen

Why this matters

Resolution records what finished the request. The state transition and the explanation should survive reopening the ticket.

Follow these steps

Open Resolve Ticket, enter the required Resolution Summary and optional Root Cause, then choose Mark Resolved. The control stays disabled while the summary is blank. Wait for the saved response; the handler requests status done with the resolution. Return to the list, adjust status filters and reopen the same ticket. Read the saved resolution and history. Use the supported state change to reopen a disposable resolved request when necessary.

Check the result

Current status vocabulary includes New, Open, Pending, In Progress, Blocked, Done and Canceled. Do not assume a separate archived list exists without verifying its UI.

05. Handle files, handoffs and failure

Why this matters

A handoff should retain the issue and message context. Failed delivery needs diagnosis before resending because the first attempt may already have arrived.

Follow these steps

Open the relevant message and attachment as the intended recipient. Change the assignee through the ticket control and verify the new staff account can continue. For a failed reply, inspect the inline error, sender and target before a controlled retry.

Check the result

Attachment, escalation and customer reply paths remain live verification branches; a static screenshot of a file name is insufficient proof of access.

Next steps

Return to the chapter for the action you need. When you change the configuration, check the matching record, customer view or destination again. A saved setting and a successful external outcome are different observations.

Illustrated examples

These illustrated examples use saved training records. Use the instructions above for the current workflow and your own records when practising.

1. Find the right support tool

The CRM menu gives you several related tools:

The top-toolbar Support menu contacts the Appmint team. It is separate from running support for your own customers.

Open CRM → Tickets. The screen heading is Support Tickets, with Tickets and Workflows tabs. The Tickets view has status and priority filters, a search field, a workflow filter, and the table of requests. Search for an existing request before creating a duplicate.

You can also reach this view from the CRM dashboard's Create new ticket quick action. In the recorded build, that quick action opens the list. You still select New Ticket to open the creation flow.

2. Write a ticket another colleague can act on

Select New Ticket at the top right. Our organization next shows Create New Ticket → Select the type of ticket you want to create, with a Ticket choice. Select it. Organizations with different ticket variants may offer a different choice; the selection determines the form you fill.

The editor has a customer summary, Ticket Details, and a Properties area. Enter this practice request:

Leave Ticket ID empty for a new request; the successful save in this walkthrough generated its number. Do not reuse our recorded number for a new ticket.

Scroll inside the form to reach Priority and Channel. Open Priority and choose Medium; then open Channel and choose Other. Check that the selected values replace the placeholders. If a dropdown is below the visible area, scroll the form so both the control and its choices can be seen before selecting. A click alone is not confirmation that a value changed.

The form also exposes Severity, Files, Assign To, Assign By, Assignments, Resolution and Shared Account Id. Do not fill these with guesses. Attach information that helps investigate the actual request; choose a shared account only when the request belongs to that business account. A reporter name, a handling owner, and a shared purchasing account are different pieces of information.

Select Save once. Wait for the saved ticket number and the new controls to appear. Our request became #AFFNR4MA. Its title, reporter, Medium priority and Other channel remained visible.

The saved request also entered Ticket support, initially at New, with a due time. The current build starts that support process on ticket save; we did not build a separate workflow before creating the request. Your organization may have different stages or timing. Read the stage and due information on the saved ticket rather than copying the four-hour timer seen in this example.

Check your result: you should have a numbered request with the correct title and reporter. If the form is still unnamed or reports a save error, do not treat it as a created ticket. Return to the list and search before attempting another creation.

3. Keep internal investigation separate from a customer reply

Select Notes (0). The Internal Notes drawer explicitly says that these notes are visible only to staff members.

Enter:

Checked the consultation checklist: room dimensions, two photos and one priority question. Next: prepare a clear reply. No customer message has been sent.

Select Add Note. The note should appear with its author and timestamp, and the ticket's Notes count increases. Close the drawer using its close button.

This note lets another colleague continue the work without repeating the investigation. It does not contact Priya. Do not put “customer informed” into an internal note unless a communication actually happened.

The Messages tab is a separate conversation history. In our no-email rehearsal it shows No messages yet and has no reply composer. The accompanying empty-state text says to send a reply, but a recipient must exist before the current ticket UI provides that composer. That is a reason to check the customer details, not to keep looking for a hidden Send button.

For an actual customer ticket, verify the recipient before responding. The current implementation provides email replies and an SMS choice when phone details are available; delivery requires the relevant configured service. This course has not yet verified a fresh external reply, attachment delivery or canned response. The absence of messages in this exercise must not be presented as a successful conversation.

4. Take responsibility, then move the support stage

Above the ticket, the handling strip initially says Open — nobody has it, with Take it. Select Take it. In our recording it changed to In progress, named Jordan, and offered Done, Nothing needed and Give back.

Notice what did not change: the ticket's support stage was still New. The handling strip answers who is dealing with this record? The workflow panel answers where is it in the support process? The form's Assign To is also a separate field; in this exercise it remained Unassigned after Jordan took the record. Do not describe all three controls as one assignment.

To start investigating, look at Workflow → Move to and select In progress. The button changes to Confirm move to In progress?. Select that confirmation promptly. In this build it disarms after three seconds; if the original label returns, select the destination and confirm again.

Check the workflow's Current stage and history. Selecting the first button without its confirmation does not complete the move. The observed support process also offers Waiting on customer and Resolved. Choose a stage because it represents the actual work, not because it makes a dashboard look complete.

5. Resolve the ticket with a useful explanation

When the request is actually addressed, select Resolve near the ticket's Notes button. The dialog asks for Resolution Summary and optional Root Cause.

For our internal rehearsal enter:

• Resolution Summary: Course rehearsal complete: checklist reviewed and support handling recorded. No external reply was sent.
• Root Cause: Preparation requirements were unclear.

This example deliberately describes the practice result. For a real request, write what resolved the customer's problem and any relevant next step. A status change cannot substitute for doing the work or communicating the answer.

Select Mark Resolved. Check that the ticket header says Done, the workflow says Resolved, and the saved summary appears under Resolution.

The handling strip may still say In progress. Finish that responsibility record separately: select its Done, enter a short outcome in What was done, in a line, then select the Save beside that field. Our outcome is:

Reviewed consultation checklist and completed the practice support record.

Do not confuse this small handling Save with the main ticket Save. They save different things.

6. Prove the work survived leaving the screen

Select the top Tickets tab to return to the list. Locate the request by title or number. The recorded row shows Done, Resolved, and COMPLETED.

Reload Studio, wait for it to restore the authenticated screen, and reopen the ticket. Read the resolution again. Open Notes: our investigation note remained, and a second entry recorded the status change from inprogress to done.

Your checkpoint: another colleague should now be able to find the ticket, understand the original question, see what was investigated, identify the handling outcome and read the resolution. A toast disappearing after Save is less useful evidence than this reopened record.

Find a resolved request when the list appears empty

From the top Tickets tab, enter the saved ticket number in Search number, title, who reported it…. In this example, searching AFFNR4MA, selecting Done from the status dropdown and Medium from the priority dropdown returns our request. Use the number generated for your own ticket.

The search and filters work together. Change the status dropdown to New and the completed request disappears: the list says 0 total and No matches. This does not mean the ticket was deleted.

Choose Any status to remove that restriction. The saved request returns. If your own search still has no matches, also return priority to Any priority, check the search spelling, and check whether In a workflow is restricting the list. Open the returned title to continue working; do not create a duplicate merely because a filter hid the original.

Read the support process as a team lead

Select the top Workflows tab. The Ticket workflows heading explains which process new tickets enter. Our training organization shows Ticket support · 0 open, 1 done, and the Resolved column contains the same ticket number and title. The process is On; leave that setting unchanged while inspecting existing work.

Read the process description to understand its configured deadlines. In this organization it specifies first response after four hours, an owner notification after one day, resolution after two days from work starting, and no timer while waiting on the customer. These are the settings shown here, not a promise about every organization's configuration.

Select Table above the board. It shows the same task as a row, including Status, Stage, Assignee and Due. Our row is done / Resolved. Select Kanban to return to the stage columns. Switching views does not change the ticket's progress.

Troubleshooting you can use during the exercise

Verification notes