When to send it
Send this midway through a beta, once testers have had two or three weeks with the product, and again shortly before you open it to everyone. A beta survey sent in the first few days mostly collects impressions of the signup screen; one sent after launch arrives too late to change anything. Email works best because beta groups are small and personal. Send it from your own address, say you'll read the answers yourself, and keep the email to a few lines.
Why these questions
The survey opens by asking how often they've used the beta, and that answer matters more than it looks. Feedback from someone who opened the product once is about first impressions; feedback from a daily tester is about whether the product holds up. Testers who haven't tried it yet skip straight to the last page, so nobody is asked to rate something they haven't used.
Active testers rate their overall satisfaction on the five-point CSAT scale, then say whether they've hit bugs and whether those bugs stopped them working. That distinction is your triage: a blocking bug that three testers hit is a launch blocker, while a cosmetic glitch can wait. Anyone who reports a bug is asked what happened and what they were trying to do, with a nudge to mention their browser or device.
The last page goes to everyone. It asks what would make the product ready for them to rely on, and how likely they are to keep using it after the beta. The first gives you a launch checklist in customers' own words. The second is an early, rough read on demand, though stated intentions are usually more generous than what people later do.
The reward
A free month after the beta thanks testers for their time and, quietly, gives them a reason to move to a paid plan instead of drifting off at launch. Unique codes stop the offer leaking beyond your beta group. Everyone who finishes gets it, including testers who never got started, because the reward is for the feedback, not the verdict.
What to do with the answers
Sort bug reports into blocking and non-blocking, and reply to each blocking report personally once it's fixed. Testers who see their report become a fix often turn into your most vocal early customers.
Group the "ready to rely on" answers and treat the biggest themes as your launch criteria. Compare the "keep using it" answers with how often people actually used the beta: if your heaviest testers are unsure, take that seriously. Once the product is live, the product-market fit survey gives you a more standard measure, and Feature feedback helps with individual features as they ship.