Playbook, SaaS company

Somebody wants into the beta, and the answer is not a date

The list here is not a queue for service, it is a register of accounts waiting for something that is not finished. People join expecting a position in a line, and usually there is no line, because invitations go out in batches chosen for reasons no customer can see. All of that is fine to explain, and none of it may be promised.

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.

  • The list is not ordered by arrival, so the reassuring answer about a position in a queue is not available and would be untrue if given.
  • What is being waited for does not exist yet in a form anybody can rely on, which means every sentence has to survive the capability changing shape or being abandoned.
  • Early access carries conditions worth saying up front: it is often limited to certain plans, it may sit outside your usual support commitments, and it can be withdrawn.
  • Most of the people asking are already paying and are asking because a colleague saw something mentioned somewhere, so the answer has to work for a customer rather than for a prospect being sold to.

How it arrives

  • how do i join the beta
  • when will the new feature be generally available
  • we registered for early access weeks ago
  • is the beta included on our plan
  • can you move us up the list
  • is it safe to use the beta with our real data

What has to be indexed for this to work

Material behind this answer
How to register interest, and what registering does not entitle you toThe form or the setting, and a plain sentence saying that registering is not a place in a queue. The second half prevents the follow up message four weeks later asking how much longer, which is the volume this pair actually generates.
The published eligibility rules for early accessWhich plans, which regions, whether an administrator has to opt the workspace in. If selection is genuinely discretionary, say that instead of implying a rule, because an invented rule is worse than an honest not everybody.
The terms attached to unfinished capabilitiesWhat support applies, whether the usual availability commitments cover it, what happens to data created in it, and your right to withdraw it. This is the paragraph that decides whether a customer should point real work at it.
Where releases are announcedThe changelog, the release notes or the notification setting. Handing somebody the place where the answer will appear is the only substitute you have for a date, and it works better than it sounds.

The reply

A reply worth copying
You can register interest on the early access page, and it is worth saying plainly that registering is not a position in a queue: invitations go out in batches and not in the order people signed up [1]. I cannot give a date for general availability and would not want to guess at one. What I can point you at is where releases are announced, so it reaches you without you having to ask again [2]. The terms covering early access, including what support applies and whether it is suitable for production work, are on that same page.

It removes the queue idea immediately, since every follow up message in this pair comes from believing there is one. Refusing the date without softening it is deliberate, because a vague soon is remembered as a commitment. Pointing at the announcement channel gives the person something to act on, which is the only thing that reduces the repeat volume.

Where it stops

The trigger. The visitor asks to be added, asks where they are on the list, asks to be prioritised, or is deciding whether to buy on the strength of something unreleased.

The handover, worded
I cannot add anybody to a list or see who is on one, and I cannot promise when something unreleased will arrive. Leave your name, your work email and the workspace name, and the team will tell you where the programme stands.

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 give a date, a quarter, or the word soon, for anything unreleased.
  • Never say an account has been added to a list, since nothing here writes anywhere.
  • Never say a place in a programme can be brought forward.
  • Never describe an unfinished capability as suitable for production work unless your own terms say so.

Questions

Can it tell somebody how long they have been waiting?
No. It cannot see a list, a registration or an account, and it should say so in the same breath as explaining that the list is not ordered by arrival anyway. Both halves are needed or the refusal sounds like evasion.
Is publishing that the queue is unordered a bad look?
It is better than the alternative, which is a customer who assumes they are moving up it and writes again every month. Batch invitations are ordinary practice, and saying so once costs less than the messages it prevents.
Prospects ask about unreleased capabilities during evaluations. What then?
Hand it to a person quickly. Anything said about unreleased work during an evaluation ends up in a comparison document, and the assistant has no way to distinguish a curious question from one that is about to become a purchasing assumption.

Keep reading

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.