Ticket

When work traveled only through conversation and chat, nobody knew precisely what was still outstanding. Something asked for in a meeting, something mentioned in a hallway, and something typed into a channel all lived in different places.

So the same question kept repeating. Ask when something will be done and there is no basis for an answer. The person doing it remembers next week; the person who asked heard this week. Sometimes two people were doing the same thing, and sometimes each assumed the other had it and nobody did.

At Pagedeck a copy change requested in a channel got buried under other conversation and surfaced three weeks later. Nobody intended to forget it. The only place the request existed was a stream that kept moving.

A ticket is one piece of work registered on a screen and given a number. The name comes from taking a numbered slip at a service counter: from the moment it is registered, the work stops being somebody's memory and becomes a row in a list. What is in a list can be counted, and what can be counted supports an answer to when it will be done.

Tools name the fields differently, but what actually gets written is usually these five.

1. The title. It is the one line visible in a list, so the distinguishing has to finish there. "Login error" tells a reader nothing; "password reset email never arrives" lets somebody scanning the list know what it is without opening it.
2. The description. Why this is needed and under what circumstances it occurs. For a bug, the steps to reproduce, the expected behavior and the actual behavior, all three. Without those three, the first thing the assignee does is not fixing it but trying to recreate it.
3. The completion condition. What has to be true before this can be closed. This is the field most often missing of the five, because whoever writes it assumes the other person obviously knows. Then the assignee fixes the sort order of search results and closes it, while the author was also expecting the empty-search-term case to be handled. That gap usually surfaces right before a release and costs a day or two.
4. A size estimate. Recording how large the work is gives you the number used to judge how much next cycle can hold.
5. Links. Hang it under something larger like an epic and the percentage complete of that larger thing falls out automatically. When one entry spans several people or several days, it gets split into subtasks beneath it.

A few attributes ride alongside: assignee, due date, priority, and the workflow status showing which stage it currently sits in. The five above are the content; these are the labels that make it findable and countable.

The fact that the writer and the readers are different people is what sets the character of this record. There are three kinds of reader and each looks at a different part.

1. The writer is whoever the request came from. Product managers write them, designers write them, and so does whoever took the customer's question. Concentrate the permission to create them in one person and requests queue behind that person.
2. The assignee is the first reader. They read the description and completion condition and start, and anything unclear gets asked in a comment on the ticket. Asking there rather than in chat is what makes the answer available later.
3. Whoever watches the flow is the second reader. They look at how many entries are stacked in each status to judge where things are blocked. For them, accurate labels matter more than individual content.
4. Whoever arrives six months later is the third reader. They are trying to find out why a screen works the way it does, and the ticket is where the reasoning lives. Make the decision only in a chat thread and never copy it across, and that reasoning is gone.

The time to write is the moment the request appears. Written up in a batch later, why the request came up in the first place has already faded. Even when a conclusion was reached in chat, many teams make copying it into the ticket a standing rule.

"Make me a ticket for it and I'll look this week."

Asking for it to be in a list rather than in someone's memory.

"There's no completion condition. How far do I go before closing it?"

Field three is missing, so the work cannot start.

"That decision only exists in the channel. Let's copy it into the ticket."

Preserving the reasoning for the reader who arrives later.

At Pagedeck, anybody can create one, and only the title and completion condition are mandatory. A thin description is accepted; an empty completion condition is rejected by the tool. Entries Sofia raises from customer questions land in the same place, and Mia sweeps through weekly to attach priority and a parent.

One rule got changed along the way. Early on, Theo simply did the things asked of him in chat, which left no record anywhere of what the week had contained. Now anything longer than five minutes gets a ticket first, with the number posted back into the channel.

The most common error is believing that more and smaller tickets means better management. The instinct that detailed records are good follows naturally. But each ticket costs the hands that create it, move it and close it. Split a thirty-minute task into four subtasks and moving the statuses takes longer than the work. People then defer the status updates and do them in a batch, and what the board says starts diverging from what is true. That is the point where the labels built to reveal the flow stop revealing it.

The second error is treating a written ticket as a delivered message. It is registered, so surely the other person will read it. But registering is a record, not an agreement. Whether the completion condition matches what the assignee has in mind is something only they can confirm. This matters most for work handed to another team: creating the ticket and discovering two weeks later that nobody has started is common. A request is the registration plus the one line telling somebody it exists.