Tickets and support
Operational manual for receiving, classifying, handling, communicating, and closing support requests.
Last updated: 2026-08-19
Ticket workflow
Requests created through the Customer Area, ISP APP, e-mail, WhatsApp, or an operator converge into one operational queue. Each ticket retains its origin, department, subject, priority, status, history, attachments, recipients, and links to the relevant customer, service, article, and assigned operator.
The module is a workflow, not only a mailbox: an incoming request must be classified, acknowledged, assigned, worked, answered, and closed with a traceable history. Before using it operationally, configure departments, inbound mailboxes, sender addresses, message templates, automatic closure rules, blacklist entries, and the permissions of every support role.
Access and permissions
Read permission covers the ticket list, detail, history, and printable information. Write permission is required for replies, internal notes, priority and status changes, assignment, association with CRM records, closure, reopening, deletion, and module configuration.
Grant configuration and destructive actions only to roles that need them. Test each support profile separately: a user who can read customer correspondence must not automatically be allowed to alter departments, mailbox credentials, templates, or another team’s assignments.
Ticket list and mailbox update
The list is the working queue and shows status, priority, subject, customer or sender, department, origin, assignment, and last reply. Open the ticket identifier or subject to inspect the complete conversation before acting; the last row alone may not contain enough context.
New e-mail tickets are downloaded automatically at the interval shown by the page. Manual download runs an immediate mailbox check and reports connection, messages found, imported, skipped, and blacklisted for each department. A successful connection does not imply that every message became a ticket: review the counters and import rules.
Filters, search, and origin
Status filters include Open, In progress, Answered by ISP, Customer reply, In progress with internal note, and Closed. Operators can also narrow the queue by priority, subject, customer or sender, department, and the other controls exposed by the list.
Use filters to build an operational view, then clear them before concluding that a ticket is missing. Origin distinguishes customer self-service, app, imported e-mail, WhatsApp, and administrative creation; it helps reconstruct the entry path but does not replace inspection of recipients, headers, and history.
Statuses and priorities
Open requires triage; In progress records active ownership; Answered by ISP waits for the next event; Customer reply returns the case to the ISP; Internal note marks private collaboration; Closed retains completed history. Priority can be High, Medium, or Low and is saved independently.
Statuses identify who should act next. High priority should be reserved for genuinely high-impact, urgent cases.
Verified Customer Area ticket
The executed case was opened and updated by the fictional customer in the Customer Area. Administration showed the same customer, sample subscription, test department, two messages, Area clienti channel, ticket number, and closure date.
Reply to the customer
A customer reply becomes part of the external conversation and may include attachments and selected e-mail or WhatsApp recipients. Review the addressees, channel, sender identity, subject, quoted history, file contents, and customer language before pressing the send action.
Preset responses and ISPINO can prepare a draft, but the operator remains responsible for technical accuracy and for removing irrelevant placeholders or internal wording. After sending, verify the local event and the channel outcome separately; queue acceptance is not proof of delivery or reading.
Ownership, transfer, and association
Take in charge moves the ticket to In progress and records the operator, reducing duplicate work. A case can be moved to another department or associated with the correct customer or supplier when the original sender was not recognized.
Priority, bulk operations, and history
Priority is saved independently as High, Medium, or Low. The list supports selected-ticket merge, close, and delete actions; verify ticket IDs and customers before any bulk operation. History pagination preserves the event trail while the PDF provides a printable representation.
Close, reopen, merge, and delete
Closure completes the case while retaining history and PDF. Supported workflows may record service time when closing. A closed case can be reopened. Merge is for related duplicates; deletion is destructive and should not replace normal closure.
Deferred notifications and cancellation
Some operator notifications are kept as pending items. Where available, Cancel notification removes an item that has not yet been processed without deleting the message or ticket. Identify recipient, event, and state first; a delivered notification cannot be recalled.
ISPINO draft and assistant settings
The generation command reads the complete history from the oldest message to the newest, distinguishes the customer from the ISP, and excludes internal notes. The draft addresses the latest unresolved request and must not turn receipt of a request into an action, task, or resolution that has already occurred.
A resolution reply confirms an outcome only when an ISP message explicitly records it; otherwise it prepares a cautious acknowledgement and states that the request will be checked. Processing and information-request drafts follow the same factual constraint. Ticket drafts do not display manual screenshots.
Treat every result as a draft and verify facts, tone, recipients, attachments, and promised actions before sending. Assistant settings require the appropriate permission and must never be populated with secrets or unnecessary customer data.
Create a ticket as an operator
Administrative creation starts by selecting the customer, after which related services, contacts, department, subject, message, and attachments can be completed. Operator-created tickets are identified in the list.
Departments and IMAP
A department defines its internal name, sender identity, mailbox, portal visibility, auto-reply behavior, SMTP, assigned operators, and signature. IMAP is optional; if started, host, port, username, and password are all required and the connection is tested on save.
Default sender and module addresses
The module also stores a default sender address for events without a more specific department identity. Keep department, SMTP account, and visible address aligned so replies do not reach an unmonitored mailbox. Validate receiving, SPF/DKIM, and reputation rather than checking syntax alone.
General settings and scheduled closure
General settings choose the default SMTP and whether tickets waiting for the customer close never, after 48 hours, or after 72 hours. The CLI cron performs e-mail ingestion and scheduled closure; the former HTTP cron route is disabled in source.
Blacklist and import protection
Blacklist rules are evaluated while e-mail is imported and can discard matching senders before their messages become working tickets. Add an entry only after confirming the exact address or pattern, its business purpose, and whether legitimate automated notices could match it.
Review blacklist counters whenever manual mailbox download reports skipped messages. Removing a rule affects future imports and does not automatically recreate messages already discarded, so mailbox retention and recovery procedures remain important.
Preset responses
Preset responses are reusable drafts organized into categories for common support situations. Give each item a clear name, keep the wording current, use only supported variables, and separate customer-facing instructions from internal procedures.
Inserting a preset never makes the answer ready automatically. The operator must adapt names, dates, service details, links, promised times, recipients, and attachments to the current case before sending.
Multichannel message templates
Automatic events cover opening, WhatsApp intake, customer replies, closure, and operator notifications. Each can provide E-mail, SMS, WhatsApp, and ISP APP content. Merge tags include customer name, ticket number, subject, department, message, URL, operator, signature, and invalid-attachment notice.
Approved Meta templates are read-only at the event level. When no override is saved, the system continues using its default text.
Automation and channels
The Ticket CLI process imports mailbox messages and applies configured automatic closure to cases waiting for the customer. The former HTTP cron endpoint is disabled. Customer Area, ISP APP, e-mail, and WhatsApp feed the same ticket model.
Delivery depends on contact and operator preferences, department assignments, and provider availability. A failed notification must never be interpreted as proof that the underlying ticket message was received.
Operator checklist
- Check status, priority, and origin
- Verify customer, service, and article links
- Take ownership before working
- Transfer to the correct department
- Distinguish customer replies from internal notes
- Review recipients and attachments
- Treat presets and AI output as drafts
- Record activities or service time when required
- Close normal history instead of deleting it
- Verify IMAP, SMTP, and automation results