Customers and requests

An issue says what the team is going to build. It does not say who asked for it, how many of them did, or how to tell them once it is done — and on a server where people ask for things, that is often the more useful half.

A customer is somebody the team tracks requests for: a member of your server, somebody who is not in it at all, or another server entirely. A request is one thing one of them asked for, kept in their own words, filed on the issue that would answer it. Several requests land on the same issue — that is the point, since eleven people asked for this is the number that decides what gets built next — and when the issue closes, everyone who asked is told, once.

This is a record of who asked, not a helpdesk. There is no queue to work through, no status to keep in step and nothing to reply to: a request is a line attached to an issue, and the issue is what the team actually works.

Turning it on

Settings > Track customers and requests, off by default. On, it adds three things:

• Customers in the page header, beside Cycles and Docs: the list of them, and a panel for the one you pick;
• Requests on every issue, under its relations — who asked for this one;
• the direct message that goes out when an issue closes.

While the switch is off, none of it is read or written. The Customers button is not drawn, no issue shows a Requests block, /task request and the two Discord menu entries refuse with a line saying where to turn it on, and no closing DM is ever sent. Turning it back off hides all of it and deletes none of it.

A customer

A customer is a Discord principal — any Discord user, or a whole server — and your server holds exactly one row per principal. A customer is not a member of yours: people ask by email, from a server of their own, or from one they have since left, and every one of them is tracked here like anybody else. Adding the same principal twice opens the row that exists rather than making a second one, which is also what happens when somebody files a request in Discord for a member who is already a customer: the row is reused, and never renamed behind your back.

Every row carries three numbers: how many requests they have filed, how many of those are important, and how many sit on issues that are still open — the last being the one worth reading, since it is what they are still waiting for. The list puts the most-asked first, and Show archived brings back the ones put away.

Adding one

New customer, on the Customers list, takes the three things a principal can be:

• a member of your server — search the members, and the name fills itself in from what the server calls them;
• anybody, by id — paste a Discord user id and the bot looks up whose it is, showing the name and the face before you add them. An id it cannot look up is added all the same: the account may be gone, or Discord may simply be having a bad minute, and neither is a reason to refuse somebody you are being told about. You type the name, and the form says the id could not be looked up rather than pretending otherwise;
• another server, by id — FlaviBot is not in it, so nothing about it can be read and the name is yours to write.

Somebody who is not in your server is tracked exactly like anybody else and costs one thing only: the message an issue's close sends is never written to them. The form says so while you add them, and their row and panel carry a quiet marker beside the principal afterwards, with the reason on hover.

Nothing files a request by itself. A customer row is a record, not a rule: a request always comes from somebody filing one, through one of the four doors below.

A request

One customer, one ask, in their words, up to 4,000 characters. Beside the text it carries:

• the customer it belongs to, or none — a request nobody is attached to is still a request;
• where it came from: added by hand, from a message, from a ticket, from a direct message, from a form, from an automation;
• a link to where they asked, so the conversation it came out of is one click away;
• important, the star;
• the issue it sits on — or a project, for something asked of a whole body of work rather than of one thing to do. Those read on the customer's panel, marked On a project; everything that files a request today files it on an issue.

Filing one

Four doors, one meaning. Each one needs Manage customers, and each one records who asked and where they asked it:

From the dashboard

Open the issue, and Add a request on its Requests block: the text, the customer it belongs to, a link if you have one, and the star. The same block is where a request is edited, starred, folded or deleted afterwards.

A request filed here names no requester of its own, so when the issue closes it is the customer who is told — which works when the customer is a member of your server, and tells nobody when it is another server or somebody outside yours. Filing through one of the Discord doors always names a person.

/task request

/task request reference:WEB-12 body:… customer:@nova important:True

reference and body are required; customer defaults to you, since somebody typing this in a support channel usually is the person asking; and important is the star. The answer is private, and names the issue and the customer it was recorded for. The channel it was typed in is kept as the link — the command's own reply is private and has nothing to link to.

From a message

Right-click what somebody asked for, Apps > Add as task request. A small form asks which issue it belongs to, with the message's text already in it, editable — trimming a three-paragraph complaint down to the ask is the whole of what the staff member contributes here. The request is filed against the message's author, so they are the one told when it ships, and the jump link to their message is kept.

From a ticket

Add as task request in the ticket options (⋯) menu does the same thing with the ticket's opener as the requester and the ticket's reason already in the form. The entry is only shown where the customers switch is on — a button that always refuses is worse than no button — and it is ticket staff only on top of the tracker's own permission, which is re-checked when the form is submitted, not only when it is opened.

What they share

The three Discord doors make a customer out of a member who is not one yet, on the spot, named after what the server calls them; a member who already is keeps their row and everything on it, archived or not. The dashboard mints nobody: it offers the customers you have, and no customer is a valid answer.

All four refuse the same things. A reference naming no issue of this server is refused the way /task view refuses one — write WEB-12, the way people say it out loud. At the customer cap, or on an issue that already holds two hundred requests, the door says so and files nothing.

When the issue closes

Moving an issue into a completed or a cancelled column sends one direct message to everyone who asked for it:

• completed — what you asked for is done;
• cancelled — what you asked for is not going to be done.

Both are an answer, and which one is sent is decided by the column's type, never by its name: a board whose cancelled column is called Won't do still owes its requesters the sentence saying the work is not coming.

Who is told is who the request names — the message's author, the ticket's opener, the member /task request named — and, for a request that names nobody, the customer, when the customer is a member. Three are not told, each for its own reason:

• whoever closed it: nobody is ever told about their own action, here as everywhere else in the tracker;
• anybody already following the issue: the same close DMed them the state change seconds ago, and one event should send one message, not two;
• anybody who muted the issue: a mute holds on every DM an issue sends.

It is sent once. Each request is stamped as told — the skipped readers' requests included, since they have already heard everything the close had to say — so reopening the issue and closing it again tells nobody twice. Several requests from the same person folded onto one issue still send one message, with a line saying how many of their asks it answers.

The card is the one every other task DM uses — the issue, what happened, and a link to its card or to the dashboard — minus Mute this issue: its reader follows nothing, and there is no stream to silence when the message is sent once and never again. As with every task notification, nothing is posted in a channel, nobody is @mentioned, and a member with DMs closed simply does not get one.

One close tells at most twenty-five requesters — past that it is a channel announcement rather than a DM list, and the card in the channel has changed for everybody already. The ones over the line are marked as told all the same, so a re-close does not go looking for them again. (Issue followers are a different list, with its own ceiling of a hundred.)

A requester who is no longer a member of the server is not DMed at all. The id on a request is whatever somebody typed, so the bot checks the person is actually here before writing to them — and a lookup that cannot answer counts as "not here": a DM to a stranger is the worse way to be wrong.

The same fence holds for somebody who was never here. A customer added by id — from another server, from an email, from a support guild of their own — is tracked in full and simply never written to; and another server has no inbox at all, so a request that names nobody on a server customer tells nobody. None of that is worth discovering afterwards, so it is shown before the fact: the customer's row and panel say they are not messaged, and a request whose requester cannot be reached is marked on the issue's Requests block, where the "they have been told" mark would otherwise go.

Folding a request into another issue

People ask for the same thing on three different issues, and two of those turn out to be duplicates. Fold into another issue, on the request's row, moves it onto the issue that really covers the work.

What it keeps: the text, the customer, the source and its link, and the star. What it remembers: where it was first filed — the row is marked as folded in, and repeated folds keep the first issue, not the previous one. What it clears: the stamp saying the person was told, so they hear about the issue that actually ships the thing rather than about the duplicate that was closed on the way.

Folding a request onto the issue it is already on does nothing at all.

Important requests

The star on a request says this one matters — the customer who will leave over it, the ask that came with a deadline. It is counted per customer, and on the board the issue's card shows how many asked for it and marks the count when any of them is starred.

That is all it does. It changes no priority, sorts nothing and notifies nobody: it is a flag for whoever reads the board, which is exactly what makes it safe to use freely.

Merging two customers

The same people end up on two rows — a member added by hand, and the server they run added later from a ticket; or simply two rows where the team wanted one. Merge moves every request onto the customer you keep and archives the one you merged, so nothing anybody asked for is lost, and the panel follows you to the row that survives.

It cannot be undone, which is why it asks first. The merged row is archived rather than deleted on purpose: the row is how a principal is recognised the next time somebody files for them.

Archiving

Archiving a customer takes them out of the list and keeps everything: their requests, their counts, their notes. Show archived brings them back into view, restoring is one click, and the slot goes back against the cap — which is why nothing here ever has to be deleted to make room.

A request filed for somebody whose row is archived lands on that same row and does not wake it up; un-archiving is a deliberate act, and the dashboard is where it is done.

A request is removed from an issue with Delete, behind a confirm, and it is gone for good. It can also be archived instead: it keeps its text and its place, stops counting against the issue's cap and is never told anything, and the customer's panel shows archived requests behind Show archived.

Who may do what

Two permissions, handed out like all the others — see who can do what:

A reporter sees them; a contributor keeps them. Reading a customer's tier and notes is more than reading an issue, which is why it is not part of View the tracker: a server can let everybody read the board and still keep who asked for what to the people who answer them.

The bot refuses the same way everywhere. A member without Manage customers reads the same sentence naming the same permission whether they used the dashboard, /task request, the message menu or the ticket menu — and in Discord, privately.

Live updates

A request filed, folded or deleted by somebody else updates the issue you are reading, and the count on its card on the board. The Customers list refreshes while you are looking at it, and is read again when you open it — a list nobody is watching costs nothing.

Limits

The same for everybody:

At the customer cap, adding one answers that the server is full — archive the ones you no longer track. At the request cap, the issue takes no more: file the ask on another issue, which is usually a sign that the issue had become a catch-all anyway.