Ticket types

Define your operation's ticket types. The type determines defaults: billing policy (billable/not), applicable SLA and flow workflow.

The type defines the workflow, SLA and template applied. It is the first choice of whoever opens the request and the one that most affects the rest: changing the type later can change the set of valid statuses.

Here you create and maintain a request type: name, icon and color (the type's visual identity), reference SLA in hours, the client and product requirements at opening, visibility for the client and the active switch. The type is the first classification of every request — and it is one of the three values that choose its SLA rule.

The list runs on the platform's standard engine: export of the entire set to Excel, PDF and CSV, saved views per user, column preference per screen and a recycle bin for deleted records (?excluidas=1 in the URL). Search and filters work by URL — ?q=text and ?fd_=value open the list already filtered —, so you can bookmark "types visible to the customer" and check the portal's showcase in one click.

The two switches make fields required when opening requests of this type: "Requires client" prevents creating the request without saying WHO the work is FOR, and "Requires product" prevents creating it without saying WHAT it is ABOUT. Turn them on for the types where that information is indispensable later — a support ticket without a client isn't billed, doesn't consume a contract and doesn't enter any per-client report. For internal types (process improvement, administrative task), leave them off so as not to create useless friction.

The type's "SLA (hours)" is a simple reference deadline, the same for all requests of the type. SLA Policies do the fine work: their rules combine this SAME type with priority and severity to give different deadlines by criticality — including business hours and separate clocks for first response and resolution. If your operation uses SLA policies, that is where the deadline commitment lives; the type's field serves operations that want a simple deadline without setting up a policy.

Everything the type carries propagates: the icon and color identify the task on boards and lists; the "requires customer" and "requires product" switches define what is mandatory when opening; customer visibility decides whether the type appears on the outside; and the type is one of the three values (with priority and severity) that choose the SLA rule. That is why a short, well-defined list is worth more than a long one: each extra type is one more decision when opening every task.

When you save a view with the Views button, it stores four things: the search text, the applied filters, which columns appear (and in what order) and which column the list is sorted by. Applying the view restores everything at once — including resetting the sort and the page you were on, so the result is exactly what the view describes. Views saved before this version remain valid: whatever they didn't store simply doesn't change when applied.

Nas fichas, sair de um campo já dispara a conferência do que dá para conferir na hora: campo obrigatório deixado em branco e e-mail mal formado. O aviso aparece embaixo do campo e desaparece quando você começa a corrigir. Campo numérico não precisa de aviso: ele simplesmente não aceita letra enquanto você digita. Isso é conforto, não a validação final: ao salvar, o sistema confere tudo de novo do lado do servidor.

Textile companies have the "Studio service" type (nature ATELIE): on the portal, the customer who picks it enters the service (sample, pattern, pilot piece), the article, colour, quantity and desired deadline, and the ticket arrives with that data at the top of the description. The default response time is 120 hours; adjust it on the type. To hide it from the portal, untick "Visible to the customer".

In the record's activity panel, each note has "Turn into request". The click creates a ticket with the note's text, who wrote it and the link to this record — nothing is retyped. Use it when the note is a request for action ("someone needs to review this"); the note stays where it was. The button only appears once the record has been saved; a read-only session (demo) doesn't create one.

Check it on the types that represent sustaining support — what the client opens through the portal with a contract behind it. These types start appearing on the Tickets screen and enter the contract's hours report. Project types, scoped improvements and internal requests stay unchecked: they remain on the Demands screen. The mark also separates what counts as support hours from what is project hours.

The portal's ticket opening form shows only the types marked as visible to the client. That is how you reduce the list of categories they see without deleting any type: uncheck the internal ones, and they disappear from the portal while still existing in here.

Whoever has permission to view this screen in their access profile — generally whoever configures the service operation, because touching the types changes the classification, the opening requirements and the matching with the SLA rules of all new tickets. The grant is made by the account's administrators on the Access screen, and the contracted plan needs to include the module: profile and plan are independent locks.

Open the record and look at the Timeline on the right: it shows each change as "from one value to another", with the person and the date. When there are many changes, use the two filters at the top of the timeline — one by field, the other by person. The search runs in the database, so old changes show up just the same. You can also ask Tenkai: "who changed contract 482?".