Playbook, developer tools company
Can we get into the beta is a request rather than a question
Developer products run things people ask to be let into: a private beta of a new interface, early access to a major release, a region that is not open yet, a client library for a language somebody has been waiting on. Joining is a matter of asking and then being selected by a person. The assistant can describe the programme and take the details, and it must not imply that either the place or the date exists.
Why this is not the general answer
The handling pattern for waiting lists holds across every trade. What follows is the part that does not.
- What is being queued for is access to something unfinished, so every sentence risks describing behaviour that has not shipped, and anything said about it will be quoted back on the day it does.
- Selection is discretionary rather than ordered. There is no position in a queue, and implying one produces an immediate follow up asking where they are in it that nobody can answer.
- A good share of these are availability questions wearing a programme's clothes, about a region, a runtime or a language, where the honest answer is that nothing is published and no date exists.
- The reader is frequently blocked on the thing they are asking for and is deciding this week whether to build around its absence, so a vague soon costs them more than a plain not yet.
How it arrives
- how do we get into the private beta
- when will there be a client library for our language
- is there a waiting list for the new region
- can we get early access to the next major release
- we registered interest weeks ago is there a position
- is the beta covered by the same support terms
What has to be indexed for this to work
| The programme description, including what taking part involves | What is being tested, what is expected of a participant, whether feedback is required and whether anything sits under an agreement. People join things they have not understood and then withdraw, which costs more than a slower intake ever would. |
|---|---|
| How to register interest, and what happens after that | The exact route, and honestly, the fact that selection is made by a person rather than in the order people asked. Saying it up front removes the follow up asking for a position, which is otherwise guaranteed. |
| Where the beta terms differ from the ordinary ones | Support commitments, stability expectations, whether interfaces may change without notice and whether anything is billable. Participants assume the normal terms carry over and are surprised by every one of these in turn. |
| The published availability list for regions, runtimes and libraries | What exists today, with nothing at all about what is coming. It is the document that lets an answer be a plain no rather than a hopeful one, which is the more useful of the two to somebody planning. |
The reply
Access to the beta is granted by the team from the register of interest rather than in the order people asked, so there is no position to look up [1]. The programme page sets out what taking part involves and where the terms differ from the ordinary ones, particularly around stability and support, which is worth reading before you commit a project to it [2]. For a client library in a language that is not on the published list, there is nothing I can tell you about timing, and I would rather say that than guess at it. Leave your name, your work email and what you are trying to build, and it reaches the team along with the rest of the register.
Saying selection is not ordered removes the follow up entirely and is more respectful than inventing a queue. Pointing at the terms difference addresses the part participants regret not reading, which is almost always the stability wording. Refusing to guess at timing is the only defensible position, and asking what they are building gives the team something real to select on.
Where it stops
The trigger. The reader asks to be added to a programme, asks when something unreleased will ship, or asks whether an earlier registration was ever seen.
I cannot add anybody to a programme or check whether an earlier registration was picked up. Leave your name, your work email and what you are trying to build, and it goes to the team who make those decisions.
It stops answering before it guesses, says who will pick it up, and asks for the one thing that makes a reply possible. Nothing about it reads as a dead end.
Never say this here
Out of bounds
- Never say somebody has been added to a programme, a register or a beta.
- Never give a date, a quarter or a likelihood for anything unreleased, however many times it has been asked.
- Never describe how an unreleased capability behaves, because nothing about it is published and the description will be quoted back.
- Never say a place is likely, or that most people who ask are accepted.
Questions
- People ask for a position in the queue. Should we build one?
- Only if you genuinely have one. A position implies an order you are then obliged to honour, and the first time somebody is admitted ahead of it you have a complaint. Saying that a person selects is less satisfying and it is true.
- Can it say whether we plan to support somebody's language?
- No, and this is where the temptation is strongest, because the answer often exists informally inside the team. Anything that sounds like a commitment ends up in an evaluation document and is raised again at renewal.
- Is there value in collecting these if the programme is closed?
- There is, provided the reply says nothing about timing. What comes back is a list of what people are blocked on, in their own words, which is a better signal than any feature request form and costs nothing to read.
Keep reading
- Everything for a developer tools companyOn a docs site an assistant competes with search, not a phone line. Version skew, deprecations and error strings decide whether it earns its place.
- Handling waiting lists in generalExpectation setting is the whole job: how the list is ordered, how contact is made, and whether a short notice cancellation can reach them.
- The deploy window is at night and nobody is at a deskChange windows and incidents both happen at night. What can honestly be answered overnight, and how a severity definition decides who is woken.
- Most complaints here are technically specific and frequently correctDeprecation deadlines, a change that broke a build, and a reader who is usually right. Answering without conceding or arguing the technical point.
- Answering a pasted stack trace without ever seeing the projectDevelopers paste the error, not the concept. What an assistant can say about a failure it cannot reproduce, and where the guessing has to stop.
Try it on your own material
Upload a document or point it at your site, paste one line of HTML, then ask it something only your business could answer.