A ticket is a record. The next action needs its own evidence.

Helpme field guide

Start with the failure the next person can recognize.

In this invented example, office colleague Rowan can open the dashboard but sees an empty panel where the ordinary materials list should appear. The subject is not merely “urgent” and the body is not a complete history of the office. A useful report names the screen, the attempted action, the observed result and the part that still works. It gives a support colleague a starting point without asking that colleague to guess which of several unrelated problems the writer means.

The ticket creation route accepts a subject, body and a named surface, with an optional priority and optional reply address. The shared draft builder trims the subject and body. Blank text is refused, an unknown surface is refused, and the default priority is normal when none is supplied. Those checks establish that a recognizable draft exists. They do not establish the cause of the failure or check whether the reporter's description is correct.

Choose a surface that describes where the problem was observed. For this adult operational example, dashboard is more informative than other. If the report concerns signing in, auth describes that area without turning a guessed diagnosis into a fact. The writer should retain uncertainty about cause in the body: “I do not know whether the panel was empty before today” is a useful boundary, not something to remove to make the request sound more confident.

A reader may object that this asks too much of a busy requester. It need not mean a long form or an elaborate investigation. One precise sentence about the attempted task and another about the visible result can be enough. The important distinction is between details the writer has and details support would have to invent. A valid report is a beginning for investigation, not a promise that the first description contains the answer.

Helpme field guide

Read the creation response as a creation response.

The implemented creation route requires authentication, derives the owner from the caller, validates the draft and calls the ticket store. Its successful response includes a ticket view: an identifier, status, summary, detail, surface, assignment and timestamp fields. The response also returns a computed support tier. Keeping these outputs separate matters because the route computes a tier from priority but does not pass that computed tier into its creation-store call.

That means a displayed top-level tier is not enough to conclude that the stored ticket has already been escalated to that tier. Read the returned ticket's own fields and the operation that produced them. An urgent input can influence a returned classification without proving that a later queue will contain a newly saved escalation. It is a small distinction in the response shape and a large distinction in an office handoff.

The same response explicitly describes AI triage as disabled. It does not supply a generated diagnosis or a drafted reply. If Rowan describes an empty panel, the accepted ticket records that description; it does not transform the sentence into a verified technical finding. A human support colleague still has to distinguish the report, an attempted reproduction and an established explanation.

Keep the record identifier with subsequent work through the appropriate existing support process. Do not use a screenshot of this marketing specimen as an acknowledgement or invent a ticket number to make a handoff look complete. An identifier is useful precisely because it points to a particular record. If creation fails, the next task is to understand that failure, not to announce that the ticket exists because the draft was carefully written.

Helpme field guide

Follow an allowed action, rather than a decorative progress line.

Helpme's legal status table is a branching lifecycle. An open ticket can be acknowledged or resolved. Acknowledged work can start or resolve. Work in progress can wait on the reporter or resolve. A waiting ticket can return to work when the reporter replies, or resolve. A resolved ticket can close or reopen, and a closed ticket can reopen. The route rejects a move outside that table with an illegal-transition response before the status write.

This allows a simple problem to resolve directly from open. It does not require an agent to click through intermediate labels merely to complete a progress illustration. Conversely, closing an open ticket is not an admitted shortcut. In the fictional panel example, an agent who has established a resolution can request resolve; close belongs after resolved. The action names are part of the contract, not interchangeable words for “done.”

A status label also has a narrower meaning than the story a reader might attach to it. Waiting on the reporter describes a work state. These ticket routes do not prove that a message reached the reporter. Resolved records a permitted workflow result; it does not prove that the reporter agrees, that every similar incident is resolved, or that a separate office task was completed. Keep those assertions attached to their own evidence.

If the screen and an earlier handoff disagree, check the current ticket before repeating a remembered action. The route reads the current state to evaluate the move. The useful question is “What action is allowed from this record's state?”, not “What did we usually click last time?” A refusal can expose a mistaken sequence without requiring a second ticket or a guessed status repair.

Helpme field guide

Name the person doing the work without inventing an automatic dispatcher.

Assignment has an explicit staff gate. The ticket assignment route permits the named support roles, takes an assignee reference or null and calls the assignment store. Null is an intentional unassignment, not an invitation for a background agent picker to fill the gap. An ordinary requester does not gain assignment authority by knowing a ticket identifier or by writing an agent's name in the ticket body.

The operational assignment surface also reports that automatic selection is unprovisioned because it has no agent-roster source. A manually supplied assignee can be recorded while automatic least-loaded or presence-aware routing remains absent. That boundary is useful in planning a desk: someone must actually make the assignment decision. The marketing page supplies no evidence of a live staff availability roster.

In the example, colleague Ellis agrees outside this illustration to investigate the dashboard panel. The manual handoff can say which question Ellis is taking and what remains open. The saved assignee field, if the authorized operation succeeds, connects the ticket to that reference. It does not record every term of their conversation, and this guide does not introduce a ticket-comment or notification feature that these routes have not demonstrated.

Helpme field guide

A calculation can suggest a change without saving it.

The escalation route is the clearest example. It validates a staff request, runs escalation rules and returns a delta, effects, no-ops and notification intent. Its result also says persisted:false. Read those fields together. An effect called applied inside a calculation is not proof that the stored ticket's priority or tier changed. Notification intent is not evidence of an outgoing message.

For a desk deciding how to handle a recurring adult sign-in problem, a calculated escalation can be material for a human decision. It cannot support the handoff “The system has escalated this and notified everyone” when the operation says it persisted nothing. Keep the proposed change, the action actually performed and the evidence of any communication separate. That makes an unfinished handoff visible instead of concealing it behind a successful response code.

The objection is understandable: why expose a calculation if it does not finish the job? A calculation can still explain how rules evaluate a case. Its usefulness depends on an honest boundary. Staff can review the outcome and determine what their established process requires. This page does not offer an alternate write path or instructions for bypassing the refusal; it explains why a result should not be rounded up into completion.

Helpme field guide

End with the ticket state and the unresolved question.

A good final handoff names what the record now says, what someone actually checked and what remains uncertain. For the fictional panel issue, “The ticket is resolved; Ellis reports that the materials panel now displays rows in the tested session” is narrower than “The dashboard is fixed for everyone.” The latter adds a scope claim the example has never supplied.

Reopening is an admitted action from resolved or closed. That provides a way to represent renewed work without pretending the earlier resolution never happened. It does not automatically prove a recurring defect, merge another report or reconstruct a conversation. Use the current ticket and the established support process to decide what the new observation means.

Finally, keep the report separate from the record. The SLA and analytics projections have their own missing measurements, explained on the work-surfaces page. Completing a ticket does not by itself turn an unavailable compliance percentage into a valid statistic. Accurate support work includes saying when the operational summary cannot support a particular conclusion; the current report must be read as it actually returns.