The tickets already wrote the brief

Do not start with a chatbot wishlist. Export last week’s tickets, or the week of ads, or the inbox that arrives before nine. The repeats are the work. The exceptions are the handoff. Everything else is a feature list that has not met the desk.

We get the same first email more often than we should.

We need a chatbot. Can you install one this month.

We write back and ask for last week’s tickets. Not a deck. Not a persona workshop. The export. Subject, body, product, time of day, whether a person had to finish it.

Most teams hesitate. Then they send the file. Then they go quiet for a minute, because they can already see it. The same five questions. The same missing field. The same “I’ll check and get back to you” that never becomes a record.

The brief is not missing. It is sitting in the desk you already run.

This is how we start. It is also how Aurelia started, and how Vesper knew the night line had to take the call and write the note. The inbox is ruder than a kickoff. That is why it is useful.

Why start from tickets instead of a feature list?

A feature list describes what someone wants to own. A week of tickets describes what customers already tried to do.

Zendesk’s CX Trends 2026 put a number on the cost of leaving that work unfinished. Eighty-five percent of CX leaders say customers will drop a brand over unresolved issues — even on the first contact. Seventy-four percent of consumers, in the same report, now expect service to be available twenty-four hours a day, seven days a week, because they have seen what AI can pretend to cover.

Gartner’s self-service research is colder. The average self-service success rate is 14 percent. Fifty-three percent of customers go straight to a person. Only 20 percent do that because they thought self-service was missing. The rest already tried. They did not get out.

If you brief a widget from a wishlist, you will decorate a 14 percent success rate. If you brief from the tickets, you will see the five questions that actually fill the morning.

A chatbot answers. An agent files the case. The tickets tell you which of those you need, and which questions a page on the site should have answered before anyone wrote in.

What do we ask to see before we write anything?

One week. That is enough. A month is better. A quarter is a research project you do not need yet.

We ask for the raw rows, not a dashboard screenshot.

If the work is nights, we ask for the overnight log, not the daytime one. Vesper did not need another weekday macro. They needed the exceptions that waited until morning.

If the work is ads, we ask for the inquiries, not the reach. That is a different brief. We wrote the Monday version of it in the number you can sit with.

We do not need your roadmap. We need the week as it actually arrived.

How do we read a week of tickets?

We print nothing fancy. We sort.

1. Group by the question the customer actually asked, not by the tag someone applied at 4 p.m.
2. Count the groups. The top five are the work. The long tail is later.
3. Mark each group: could a true page have closed this, could an agent close this with a tool, or does a person have to finish it.
4. Open the three longest threads in the top groups. Read them to the end. The end is where the document lies.
5. Write the brief in one page. What we would answer. What we would file. What we would refuse.

That is the whole method. It takes an afternoon. It saves a quarter of building the wrong widget.

The top five groups are the agent. The exceptions are the handoff. The pages that were wrong are the knowledge project. If you skip step four, you will train the agent on the lie that caused the ticket.

Gartner tells support leaders to treat self-service as a product, not a project, and to measure case deflection as people who intended to contact you and did not have to. You cannot measure that from a wishlist. You can measure it from last week, and from the week after you ship.

What does a one-page brief from tickets look like?

Not a deck. Not a persona. Four headings.

What keeps arriving. Five questions, in the customer’s words. Counts if you have them. Times of day if the nights are the problem.

What a true answer would do. Close it. File it. Or pull a person in with the thread attached.

What we will not build. The seventh intent. The cute opener. The widget that cannot write a record.

How we will know on Monday. The same five groups, next week. Not a satisfaction score from three people who finished a survey.

On Aurelia the first page looked like this, anonymised.

SSO reset. Workspace ID missing. Invoice PDF. “Where is my seat.” “This is the wrong plan.”

Four of those could be answered from a clean help centre and a tool that can see the workspace. One needed a person, because it was a contract. The previous widget had answered all five with a paragraph and a smile. The morning pile did not move.

We did not install a personality. We installed the four, and a handoff for the fifth. That is a brief. The wishlist had been “an AI assistant for the whole journey.”

Why do feature lists make such bad briefs?

Because they are written in the room that does not receive the tickets.

The room writes “onboarding,” “proactive engagement,” “omnichannel.” The desk receives “the invite link expired” at 2 a.m. Those are not the same job. One is a category. The other is a unit of work.

Zendesk’s 2026 trends also say 83 percent of CX leaders believe memory-rich agents are the key to personalised journeys. Memory is not a vibe. Memory is last week’s workspace ID, last month’s invoice, the page that was wrong. If you do not start from the tickets, you will buy memory as a slide and ship a widget that cannot see the record.

We have sat in kickoffs where the feature list ran to forty-two lines and the inbox, opened on the same table, had six questions doing 70 percent of the volume. The list was not dishonest. It was written from hope. The inbox was written from Tuesday.

Hope is not a brief. Tuesday is.

What if we do not have tickets yet?

Then you still have a week.

The site search log. The sales inbox. The “just checking in” emails that are actually “where is my order.” The ad comments that repeat the same objection. The form that collects a message and files it nowhere.

If you are pre-launch, you have the questions the founder answers on every call. Write those down. They are tickets that have not found a desk yet. They are still more honest than a feature list copied from a competitor’s pricing page.

If the week is empty, you do not need an agent. You need to be findable. That is a homepage problem, or an ads problem, not a model problem.

How does this change the site, the ads, and the agent?

The same five groups usually split across three surfaces. That is why we refuse to brief them as three vendors.

When the same question hits the ads, the landing page, and the inbox, you do not need three answers. You need one, written once, and a landing page the campaign and the agent can both use.

The tickets already told you which row you are in. The wishlist usually pretends you are in all of them.

How do we run the first week after we have the export?

We do not open a builder on day one. We write the one-page brief. We mark the pages that are not true. We name the two tools the agent would need, if it is an agent. We name the handoff.

Then we sit with you and refuse. The seventh intent. The opener that performs hospitality and files nothing. The knowledge article that still says the old price.

If we cannot refuse anything, we are not ready to build. That is the same rule as the homepage test: if we cannot write it simply, we close the lid.

The install comes after the refuse list. Not before.

What should you send us on Monday?

Last week’s export. The ten longest threads. The current help URL. If nights are the pain, the overnight log.

We will write back within 24 hours with what we would start, and what we would leave. The note is yours. You can take it to another firm. Most people do not, because the note already looks like their Tuesday.

Do not send a chatbot wishlist. The tickets already wrote the brief.

FAQ

Do we really need a full week of tickets?

Yes, if you have them. A week shows the repeats and the nights. A single “typical ticket” is a story. A week is a pattern. If you cannot export a week, you are not ready to brief an agent. You are ready to fix the desk.

What if the tickets are messy or untagged?

Send them messy. We group by the question, not by your taxonomy. Clean tags are useful later. They are not the brief. The body of the ticket is the brief.

Can we start with a chatbot and upgrade later?

You can. Most teams then switch it off, because the morning pile does not move. We wrote the difference in chatbot vs AI agent. If the conversation cannot file a case, you have bought a reply. Buy a reply only if the tickets show that a reply is the whole job.

What if most tickets need a person?

Then the brief is a better handoff and a cleaner page, not an agent that pretends. An agent that cannot finish the work and cannot hand it over is worse than no agent. The tickets will tell you the split. Believe them.

Is this only for support?

No. Sales inboxes, ad comments, and form dumps work the same way. The question is always: what keeps arriving, and what should happen to it. Support is just the desk that already has an export button.

How is this different from a discovery workshop?

A workshop produces a deck. A week of tickets produces a one-page brief you can argue with on Monday. We still talk. We talk about the file, not about hypothetical journeys. The file is ruder. That is the point.

What do you do with the knowledge articles?

We read the ones the tickets pointed at. If the article is wrong, the agent will be wrong. That work has its own name: the document was wrong. We do not train on a lie because the lie is formatted nicely.

Will you sign an NDA before we send tickets?

Yes. Send the NDA with the request. Do not anonymise so hard that the product and the time of day disappear. We need to see the work. We do not need the customer’s private life.

---

If last week is still in the desk, send it. Start a project and attach the export. We will tell you which of the five groups is the work, and which we would leave on the table.