Who to invite before opening your new service to every customer

Invite for learning and service continuity

Suppose a small Hong Kong consultancy has a working portal for submitting documents, checking a request and receiving an adviser’s response. The owner needs to decide which customers can use it next week. Start with a deliberately mixed, limited invitation list. Choose people with a real task during the trial period, including customers who need more help. Keep an agreed existing route available for urgent work that the trial cannot safely absorb.

The GOV.UK Service Manual describes private beta as limited access used to gather feedback and improve a service; wider access follows confidence in operating at scale. It also calls for capacity to keep improving and supporting users. This is UK government delivery guidance, not a Hong Kong requirement. The cohort table and release conditions below are our proposed application to a small firm, not prescribed thresholds.

An invitation-only trial trades reach for control. Opening to everyone gives broader exposure but can create more simultaneous problems than a small team can investigate. Inviting only friendly power users is easier to support but leaves ordinary difficulties unexplored. A first-come waiting list is simple to administer, yet may miss customers using different languages, devices or approval arrangements. Use explicit selection reasons rather than customer prestige or enthusiasm alone.

Build the invitation worksheet

For the consultancy, use one row per invitation reason and replace role labels with named staff before sending anything. A customer can cover several characteristics, so count that customer once in the total. Ask about preferred language and support needs instead of assuming them from age or job title. Include awkward but recoverable tasks; a live deadline with no recovery route is a reason to defer that case, not a useful stress test.

Suggested selection criteria, not quotas or observed results. Choose cases within the working service’s supported scope.

Set the batch size from available help

Use a conservative workload check before choosing a batch. In this illustrative example, one coordinator has 180 minutes reserved for pilot support in a week. Hold back 60 minutes for unexpected follow-up, leaving 120 minutes. At an assumed 20 minutes of total support per invited customer, 120 divided by 20 permits six invitations. This assumes all six activate that week; it is a planning ceiling, not measured demand or evidence that six is an ideal cohort.

The 20 minutes must include onboarding, questions, notes and repeat contact for each customer. Developer fixes and the owner’s review time need separate availability; the calculation does not fund them. If expected support rises to 30 minutes per customer, the same 120 minutes supports four invitations. Reduce the next batch when actual casework or unfinished cases consume capacity. Spread starts across staffed periods, and count earlier invitees who activate late before releasing more invitations.

Make participation understandable: state which task the customer can try, when help is available, how to report a problem and how to continue through the existing route. Give an invitation expiry or a reconfirmation point so dormant invitations do not become an unexpected later surge. Participation should be optional. Record whether someone declined, never started, abandoned the task or completed with staff help; silence alone says nothing about usability.

Make a recorded decision after each batch

Give one service owner responsibility for combining feedback and deciding the next intake. Keep a compact case log: task, language and device, expected result, actual result, support minutes, unresolved issue, responsible person and follow-up date. Separate a defect from unclear wording, a training need and a feature request. Return fixes to an affected participant for a fresh attempt where appropriate. A small selected cohort can reveal problems, but cannot establish a population-wide success rate.

Before sending the next batch, review whether ordinary and awkward cases reached a confirmed outcome, whether promised support times were met, and whether remaining work fits the rota. Pause invitations for lost submissions, inappropriate access or a growing unresolved queue; nominate an owner to recover affected work. If one language or device route remains unproven, retain limited access for it and record the gap. Widen gradually only when the team can explain the evidence and handle the additional work.

Your next action is a short meeting between the service owner and the support coordinator: fill the worksheet with actual invitees, reserve their support windows and agree a review date before issuing invitations. If the bottleneck is recurring human assistance, use the related support-budget guide. If the trial reveals a portal workflow needing development, take the case log to a scoped software discussion so the proposed change addresses a recorded obstacle.