Trials are tricky. You have countless options, and there’s no perfect approach. How long should a trial last? Should you be generous extending trials? Should you require a credit card up front? Should you have a free forever option? How much information should you gather? Should you require people to confirm their accounts? Should you let people sign up with Facebook, Twitter, or Google, or other preexisting accounts?

Each of these questions leads to complex trade-offs depending on your application, audience, and a variety of other variables. Unsurprisingly, the answer to each of these questions is: “It depends.”

Before we dive into the specifics, let’s change something a little bit. Don’t think of that initial form as a sign-up or registration form. Think of it as an “introduction.” The problem with most sign-up processes is that they move away from the natural progression of trust-building. They demand a lot before they give anything. Some applications won’t even share pricing information unless you submit to their lead generation form. (And I am intentionally using the word “submit”, literally and figuratively.)

If you switch the mentality from capturing leads to enticing visitors, things change really quickly. Your product may be so customized for each customer that personal demos may work best, but nobody likes friction. Focus on earning trust rather than demanding it. Requesting personal information so someone can try your software is asking a lot. Imagine walking into a store that demands you sign their list and provide personal details before they let you in to browse. You might agree, but you won’t be happy about it.

How can you flip traditional registration on its head and give a little more before demanding anything? Could you give them limited access without gating your application with a sign-up form? Could you let them use your application without ever signing up? You record their usage and tie it to a cookie, and then provide a prompt that offers to let them create a trial and save their data. If that’s not right for your application, can you provide more demo videos and screenshots prior to registration so they can see how things really work, without giving you personal information?

Alternatively, what’s the absolute minimum amount of information you need to start people on a trial? Is an email address enough? Do you really have to have their name or force them to create a password before they’ve even decided if they like what you’re offering?

For some services, spam and fraud are a real problem, and letting unknown visitors use your software can be virtually impossible. In these cases, you could limit functionality for passersby, but enable that functionality once they’ve registered and confirmed their email address or taken other steps to validate their legitimacy. (I’ll address tactics for dealing with spam and fraud in detail separately.)

A similar option with less risk is to have public demo accounts with realistic dummy data for visitors to test drive. This can be more technically complex, but it’s a great alternative to forcing people to register.

At this point, if you have a high-touch sales background, you could argue that too many leads will slip through the cracks if you don’t demand contact information. I’d argue that you’ll end up with better qualified leads with a little more inherent trust because you gave them something.

The short version is that the sooner you get visitors engaging with your product and trusting your business, the better off you’ll be. Think of it as extreme friction reduction.

The next common question is whether to enable sign-ups via Google, Facebook, Twitter, LinkedIn, or other preexisting accounts customers may have. This can dramatically reduce friction, but sometimes it complicates logins for returning visitors. The other important factor to consider is that requiring sign-up via one of these methods could likely alienate a significant portion of your audience. Requiring registration via a social media account may turn away people who don’t have one or aren’t comfortable sharing it with you yet. Furthermore, requiring write-access to someone’s social media account is often a nonstarter. When you demand more permission than you’ve earned, you could lose customers who would otherwise love your product.

Regardless of how your visitors begin their trial, the next question is how long that trial should last. Generally speaking, people won’t pay until you make them. So all things being equal, a 7-day trial will convert sooner than a 30-day trial. However, a 7-day trial may be too short if your application involves users inviting and collaborating with teammates. My advice is to lean towards shorter trials with a strong willingness to extend the trial if people need more time.

I strongly suggest providing users with a way to extend their own trials under the right conditions. With Sifter, probably 15–20% of the support requests were from people who needed a little more time to evaluate it. In 99.9% of the cases, it was clear they hadn’t started using it. They may have only logged one or two issues and not invited any teammates. I should have implemented a simple self-serve trial extension, but I never did. By simply checking an account to ensure they had created less than five issues, I could have let anyone extend their own trial on the spot without contacting support. I could also have tracked how many trial extensions they had and factored that into the self-service option. This would have been a much better experience for customers, and it would have reduced support requests. If they don’t meet the requirements for a self-serve trial extension, you can still ask them to email support to extend their trial.

You might also be wondering if you should require a credit card up front. This is complex as well. On one level, it can serve as a great filter to know whether a visitor is serious; on the other hand, it may scare off customers who would otherwise be a great fit. Often, with business customers, the person evaluating your software isn’t the person with the credit card. In that case, they’d have to sign up with their personal credit card. Some might, but many won’t. In many countries, credit card use is uncommon. That may be an acceptable loss for you, but if you assume everyone has a credit card, you’d be incorrect.

The other side to requiring credit cards up front is that if you charge the provided card when the trial is over, you could end up with chargebacks. Even if you notify people before you charge the card, people can miss the email, be on vacation, or have other extenuating circumstances. Your conversion rate from visitor to paying will be higher, but at what cost?

If you want to require credit cards in advance, my advice would be to not charge it automatically. Instead, freeze the account like you would with any other trial and email the user with a simple message asking them to opt in, charge the card, and start their paid account.

A last thought about email validation: if you require an email address during registration and send a confirmation email, don’t require the visitor to immediately check their email to confirm the address. When you do this, you’re sending them away from your application before they’ve had the opportunity to develop an appreciation of it. If your confirmation email is slow or delayed, they may never come back. Instead, let them look around and perform some basic activities, and only secure the risk-prone areas of the application, like payment forms or sending email, until the visitor’s email address has been confirmed.

Do everything you can to minimize visitors’ effort during the registration process, and make sure you’re earning trust before demanding it. It will change the tone, and your application will immediately stand out from other more intrusive applications and sales processes.

Killing Sign Up Forms Luke Wroblewski delves into a variety of ideas for reducing sign-up forms and leaning on gradual engagement to cut back on friction and help visitors test drive your software.