[HN Gopher] A fourteen-day free trial ain't gonna cut it
___________________________________________________________________
A fourteen-day free trial ain't gonna cut it
Author : ezekg
Score : 316 points
Date : 2024-05-06 13:50 UTC (9 hours ago)
(HTM) web link (keygen.sh)
(TXT) w3m dump (keygen.sh)
| arnon wrote:
| I made a beeline to the median, because funnily enough my median
| for other B2B SaaS was also 41. I feel vindicated!
|
| For consumer stuff my experience was closer to 25, but for
| businesses it was 41.
| seurimas wrote:
| Interesting! 25 business days for a business is close to 41
| calendar days, too. I wonder if there's some sort of common,
| human constant involved. 25 days of engaging with something to
| decide whether that something is worth keeping around. Maybe
| the median relationship length is 25 days, too...
| PaulHoule wrote:
| As a software dev I can say this is so true. A 14-day free trial
| is not free, it costs your time.
|
| It takes a serious block of time to evaluate any product or
| service, maybe a few days. If I put a few days into an open
| source product and I like it I can just use it. If it is a paid
| product I'm going to have to go to my management, it might be
| easy or it might be hard, but I have to discount the gains from
| "I found a product I like" by the probability that "we won't buy
| it anyway" so that makes me all the more hesitant to complete a
| trial.
| garciasn wrote:
| My team is responsible for the research, evaluation, approval,
| integration, and on-going support for each and every single
| platform that is within our stack. We have a lengthy
| standardized process for evaluation/scoring/approval and one of
| our mandates is a minimum of 30 days, no payment, and no
| Sharewaresque limitation in functionality. If we cannot get 30
| days, it's a simple 'no,' and we move on to the next.
|
| Even at 30 days, it's extremely stressful on the team to get
| the system up and running, ingest our test case data, and run
| our tests. This is after going through this process >100 times.
| There's simply no way to get everything that needs to be done
| with an evaluation of even basic coverage in less than 30. Full
| stop.
|
| Lack of adequate understanding of the potential challenges an
| org is going to face during implementation and use is, IMO, the
| single biggest reason implementations run WAY OVER budget,
| time, and eventually fail at integration w/the rest of the org.
| This is entirely ignoring the required change management, which
| is another beast entirely.
| carlosjobim wrote:
| It sounds like you're bragging about a dysfunctional way of
| working. If what your team is doing is valuable they should
| get any tools they like without much questions. Just like in
| any reasonable workplace. Because workers produce more and
| better when they have better tools.
|
| You can also just buy the software to evaluate it. This way
| you have unlimited time to see if it fits or not. That's what
| people do in other industries.
| kfarr wrote:
| Yeah it is a bit odd to say that the #1 requirement is that
| the software be free for 30 days, that would disqualify a
| bunch of critical infrastructure.
| p_l wrote:
| A lot of _multiple thousand dollars per seat_ software
| will offer evaluation licenses, for various lengths of
| time, sometimes way longer than 30 days.
| dijit wrote:
| Theres a quick fall-off.
|
| Sourcegraph is $99/u/m and has major network effects. For a
| moderately sized org this is quickly an entire developer
| salary.
|
| Snyk is similarly priced, unfortunately "just buy" is a
| really easy way to:
|
| a) pay more than something is woth
|
| b) have multiple products doing the same thing. (for
| example, I have Miro _and_ figjam _and_ Mural in my company
| because each do something slightly better and teams have
| chosen the tools that work best).
|
| That means we often double pay on licenses for ostensibly
| similar software.
| sqs wrote:
| Sourcegraph CEO here. It's not $99/user/month anymore.
| It's great that a lot of companies were willing to pay
| that, but we and our customers prefer a lower per-user
| price and a higher % of devs at the company using it
| (ideally 100%). We reduced prices for our customers
| (current and future). You can see the posted pricing at
| https://sourcegraph.com/pricing.
|
| For any other dev tools companies, I'd strongly recommend
| having lower prices so that every dev at your customer
| can use it (if that's relevant for your product). If you
| start seeing customers be really picky with who gets a
| license, it's probably priced too high.
| CamelCaseName wrote:
| Off-topic, but I see you always responding very quickly
| whenever Sourcegraph is mentioned.
|
| I was entertained a while back when I saw you getting
| accused for using sockpuppets, but am I correct in
| thinking that you're probably just using the API to
| monitor for name mentions?
|
| Edit: To be clear, I think this is great and that more
| companies should do this.
| jdorfman wrote:
| Syften & Common Room =)
| sqs wrote:
| Haha, yeah, @jdorfman's sibling comment mentions the
| tools we use. Any mentions on HN, Reddit, Twitter,
| YouTube, etc., show up in our team chat. The gold
| standard, of course, is Sid at GitLab ("GitLab CEO here"
| :).
| carlosjobim wrote:
| A) You don't need to buy the software for every employee
| at once. Why not buy it for a dozen and try it? If it's
| good you get more licenses.
|
| B) You can buy software and evaluate and decide not to
| use it and cancel the license.
| dh2022 wrote:
| Well, maybe a way to let workers try out better tools and
| not explode the budget /complexity of the tech stack is to
| give devs $500 / year to spend on whatever they want. It
| could be monitors, a new IDE, etc.... This way individuals
| can try out a new tool and if they really see itts value
| they could "sell" it to management.
| PaulHoule wrote:
| Even where there hasn't been a formal policy I usually
| haven't had a hard time getting anything that costs, say,
| $50.
| carlosjobim wrote:
| $500 per year is a pathetically low amount for a dev who
| is expected to make his company hundreds of thousands or
| millions per year. Plumbers and HVAC specialists have
| tools worth tens of thousands of dollars.
| ultrasaurus wrote:
| This sounds very much like an "enterprise" sale, with a sales
| rep who can help with checklists and presumably extend your
| trial quite a bit.
| dylan604 wrote:
| In my experience, I've only looked at new software when the
| text on the box says that it'll solve an issue we currently
| have, dramatically improve existing workflows, or specifically
| asked by someone else. If you're concerned about _time_ , then
| maybe you (or your company) are doing it wrong. Depending on
| the size of your company, there should be a team of people
| assigned time to specifically evaluate theNewShiny whatever. If
| the product does not do what is advertised on the tin, then
| drop it and move on. If it does work as advertised, the team
| then evaluates next steps in how to utilize it. In this way,
| that research is already "budgeted" into employee's time.
| tomjen3 wrote:
| Sounds like you need a first filter, and then only do your
| evaluation process on a given product if it solves a major pain
| point and even in that case, just evaluate the best/most common
| product in that category and only if it clearly doesn't work
| test another product.
|
| You are not going to win as a startup by using Teams, even if
| it is cheaper than Slack+Zoom, you are going to win big or not
| at all and focusing on things that don't matter for the core
| success just means less time to make something people want.
| gregmac wrote:
| And the time to evaluate for something you're releasing (vs
| staying in your control on SaaS) is significantly higher.
| Things that lock you in, especially between your released
| software and hosted services -- like authentication,
| installers/auto-update, and licensing (keygen) -- are even
| higher than that.
|
| It's just really hard to "undo" these things, both technically
| and because of the optics (user experience). Requiring your
| users to re-license their software is friction -- it burns user
| trust and costs a lot of time in support.
|
| 14 days is just too short to evaluate if the product will even
| meet your needs, let alone evaluate how much lock-in there is
| and what the path away could look like.
| dangus wrote:
| Implementers failing to prioritize doing some legwork during
| the free trial period also costs time for the sales
| organization of the selling party.
|
| From the sales side, if we see the prospect the finding a
| solution is a low enough priority that their engineers can't
| spend time in two weeks to simply look at a solution, then they
| might not be an ideal fit for the product (they don't enough
| business pain, don't have a champion, and/or don't have an
| economic buyer to prioritize the purchase of a solution).
|
| This is of course highly dependent on the nature of the
| software and the ideal customer profile of that solution, but
| the fact that there's two sides of this coin is something to
| keep in mind.
| barfbagginus wrote:
| In many orgs, pain points are subtle, product evaluations
| happen on the back burner, and internal consensus on pulling
| the trigger might take months. These firms are left on the
| table by a demo/sales process that can only afford them two
| weeks.
|
| And a trial need not take many sales resources. We can
| automate that with a demo download and self serve
| documentation. If it's an on prem demo, a 2 week or 12 week
| trial costs us the same - it's just a sign up and download.
| We don't actually need a sales rep to prod them about buying
| - the demo countdown does that, for people actually gaining
| value from the demo.
|
| Let's acknowledge the article's evidence that longer trials
| can convert customers with lower pain points. Secure
| customers like to evaluate things without pressure. And they
| might be the majority of customers.
|
| Let's enable this by building sales resilience, engineering
| the infrastructure painlessly delivery a longer trial that
| takes near zero sales or production effort.
| dredmorbius wrote:
| From the ops side my situation's similar.
|
| The more so as the team is often small (one-person ops teams
| are probably the norm, at least by number of establishments),
| and workload is often _already_ overwhelming.
|
| New technology and/or products _always_ come with unanticipated
| consequences and downsides. Expecting to make a decision on a
| major, or even _minor_ tool isn 't something that can be
| rushed.
|
| One model I'd noted as innovative at the time was for a SAAS
| company to offer a free tier of service, in the case in mind,
| with limited data retention of a monitoring tool. That struck
| me as an exceedingly good way to balance the power of the tool
| (all other features were otherwise available), whilst also
| providing a clear _and reasonable_ upgrade path to a paid
| subscription. When that company IPO 'd and revealed its CoS
| (cost of sales), I was surprised to see how high it remained
| (on the order of 40--50% of revenues).
|
| Selling (and buying) complex information goods is _hard_ ,
| whether that's software, services, consulting, news, or
| anything else. There's a copious literature on the _production_
| side addressing the zero marginal cost / high fixed costs
| predicament. There's less on the _buy_ side, though Akerlof 's
| "Market for Lemons" addresses this in part. Reducing
| uncertainty, increasing knowledge, and mitigating purchaser
| risk _without needlessly offsetting revenues_ seem key to the
| issue.
| nick7376182 wrote:
| I wonder if for a larger consumer product this would not work, as
| word gets around they can stay free for a long time. Though it
| seems to work for a lot of community software like makeMKV.
| alexcaza wrote:
| Nice write-up! This is a great example of throwing out "best
| practices" and being truly user/product-centred. Even down to
| your trial strategy.
|
| It reminds me of YNAB's trial[^1] strategy of offering 34 days.
| It gives folks just enough time with their app and process. I
| wish YNAB's trial extended to ~60 days since my "ah ha!" moment
| was only around then. That's another conversation, though.
|
| ^1: https://www.ynab.com/sign-up
| Suppafly wrote:
| I imagine 34 days is so that you have enough to budget around
| an entire month. Would be shitty to setup a budget and not be
| able to follow it for a whole month.
| alexcaza wrote:
| Yeah, exactly. Their whole thing is to get ~30 days ahead,
| too. I think 60-90 days would be a better hook and almost
| guarantee an "ah ha" moment. Everyone I've spoken to that's
| had YANB "click" was in that time frame, myself included.
|
| I wish I could see how a trial length change would affect
| their conversions.
| simonsarris wrote:
| I sell a JS/TS graphing library, so B2B, developer-to-developer.
|
| We decided to just have an indefinite trial period (library has a
| watermark) and instead offer _30 days of free support_. That way
| we can help people get started and realize their proof of
| concept, but if they want to start evaluating on their own time
| they can do so without worrying about any clock. This makes it
| much easier for customers who are trying to evaluate multiple
| options at once.
| go_prodev wrote:
| I'm always exploring new graphing libraries. Are you happy to
| share a link to yours?
| martincmartin wrote:
| If you click on their username, it takes you to their
| profile.
|
| https://news.ycombinator.com/user?id=simonsarris
|
| which says:
|
| _I make GoJS, a powerful canvas-based diagramming library:_
|
| _http://gojs.net/_
|
| Which is not what I think of a graphing (time series, x-y
| points joined by lines), but otherwise seems relevant to
| their comment.
| simonsarris wrote:
| Thank you. I guess I should update that, since GoJS renders
| to SVG also if that's what you prefer (at a cost to
| performance of course)
|
| Most of us who make such libraries tend to distinguish
| charting (time series, lines, bars) from graphing (nodes
| and links). Charting is, in many aspects, a much smaller
| problem space. Graphing requires a lot more in terms of
| layouts and interaction tools, grid snapping, guides,
| undo/redo, copy/paste, grouping, subgraphs, managing user
| permissions for interactivity, expand/collapse (both
| subgraphs and tree sections), updating the backing data
| when the graph is edited, etc.
| newswasboring wrote:
| It's very surprising to me that there is a market for this.
| But then again I have spent almost my entire professional
| programming career writing matlab. How does one even
| identify such a market? I am so curious, please share your
| story.
| simonsarris wrote:
| The extremely condensed story of my company (started
| ~1995 when I was a tiny child, I joined 2010, though now
| I am part owner) was a bunch of guys in an advanced
| research division of Digital, trying to make a visual
| programming language. After Digital went under they kept
| trying to do this, but no one wanted the language. People
| however were interested in the graphic tech used to make
| the language, so they turned that into a library, in the
| 1990s, called Go++ (Graph Objects for C++).
|
| Then JGo (Java), GoDiagram (C#, WinForms and now
| Avalonia), GoXam (XAML/WPF C#), and GoJS.
|
| I began GoJS as a greenfield project starting in
| 2010-2011 as a new grad by working with these guys who
| had been thinking about diagrams for years. So it had the
| advantage of being built from scratch (and using the
| brand new HTML Canvas surface) but with all the
| accumulated experience of their wisdom at hand any time
| there were design questions. In some sense I got really
| lucky to work on such a "brand new, but charted path"
| project. Not many new grads get that kind of
| experience...
|
| When we released GoJS I was unsure if anyone would
| actually pay for JavaScript library. There weren't too
| many I could find in the space that weren't free (Sencha
| was one I found while doing research, and funny enough
| they tried to recruit me, flew me out to CA after I wrote
| a book about canvas circa 2013). But the problem space
| really truly is large, and you can save a year or more of
| development time by buying such a library, so the
| calculus is very worth it for many companies. Like so
| many people, what we sell is time, and having thought
| hard about these problems for so long, from layouts to
| really mundane undo/redo transactional stuff.
| neeleshs wrote:
| This is very true in my experience as well.
|
| This is a key component for any good low/no code
| platform, process builders, workflow builders , process
| documentation and so on. And that is just one area.
|
| It makes tons of sense to buy/use a library like this
| rather than build your own (unless that is your
| business). We use one from antd. Antiquated and hard to
| automate testing. We are looking for a more modern
| solution.
|
| How compatible is GoJS with web testing tools? Most seem
| to have trouble with canvas.
| simonsarris wrote:
| I would say "fairly annoying", alas! I never bothered to
| make Selenium etc examples, though I know some customers
| use it. You can switch to the SVG renderer for testing if
| you really want to inspect the DOM after doing actions,
| and some customers do this too. And you can mock events
| if you want to, we give some basic examples:
| https://gojs.net/latest/samples/Robot.html
|
| But you have to inspect programmatically one way or
| another. What is easiest really depends on what, exactly,
| you want to test. Eg testing your permissions (can a user
| copy a node with these checkboxes in my app selected) can
| be done by trying to copy and seeing how many Parts exist
| before and after, etc.
| recursivecaveat wrote:
| Can I ask how large your library can scale to? We have
| digraphs in the range of tens to hundreds of thousands of
| nodes, and every tool I've tried falls over. The layered
| digraph example from your site seems to hang forever at
| 10k, but that could just be how the example widget is set
| up.
| cess11 wrote:
| You can make it a business to build and license a
| JavaScript calendar widget. Many companies would rather
| buy such a library than have their developers pick
| something FOSS or develop on their own.
| TillE wrote:
| Time limited trials are always a feels-bad moment for me, an
| extra deadline I now have to plan around.
|
| Another option I like is providing some amount of free credit
| that doesn't expire. So you're not on the hook for providing a
| "free tier" forever, but users can play around with your service
| at their own pace.
| kevincox wrote:
| This is what I am doing (business to consumer) and I am quite
| happy with it. I am maybe a bit too generous with the free
| credits (many people can use the service lightly for over a
| year on the trial) but I like that they get the exact
| experience as if they were paying and they can pause and resume
| their trial with no extra complexity on my end. Just sign up
| and you get some starting credits. Then you can just buy more
| as you need them. I think it makes things simpler and avoids
| any sort of pressure.
| gregmac wrote:
| This would work for B2B as well.
|
| Sometimes there's a shifting business priority, and guess
| which wins when the choice is "important customer X is on
| fire" vs "our developer trial for wizbang component xyz is
| going to expire in 8 days".
| cableshaft wrote:
| I also don't mind something like '30 days' or '60 days', but it
| only counts the days when you open the application.
|
| Like a few weeks ago I was motivated to learn some music
| production software, so I downloaded a few trial versions. I
| worked on it heavily for a few days, but then got busy with
| other things, and now that 30 day trial or whatever is coming
| up to an end, but I still don't feel like I've had a chance to
| decide if it works for me, because I haven't been actively
| using it that long yet still. I do plan to go back to it, just
| maybe not for another week or two.
|
| But if it only counted the days I opened the application, I'd
| still have like 26 'days' left to evaluate them (they might, I
| haven't checked), and it'd be no big deal, and I wouldn't have
| to feel all stressed out because I'm 'wasting' the demo time by
| actually having a life and maybe badly timing when to trigger
| the trial period.
| bombcar wrote:
| This has happened time and time again with B2B systems - I
| sign up for a trial, begin poking it, and then work happens
| and by the time I go back the trial is dead.
| raldi wrote:
| Exactly. Another good model for certain kinds of product is to
| allow unlimited use of a limited dataset.
| rrrrrrrrrrrryan wrote:
| Time-based free trials are fine for one-time purchases I think.
| It's basically the equivalent of a return window, without
| collecting money upfront.
|
| Where they don't make sense is for subscriptions, because
| subscriptions are by definition something your users will be
| using for a long time, and it might take them a while to
| realize all of its value and get hooked.
|
| For this stuff a free tier that funnels customers to the paid
| tiers usually works best. You can play with limitations by
| restricting features, or usage, or anything else, but you
| probably shouldn't restrict them based on how much time has
| elapsed since they first signed up. Let them get hooked at
| their own pace.
| nikolajan wrote:
| I get the sense that a 2 month trial would have been a better
| option (41 days + buffer). It provides clients with the required
| amount of time to get up and running while also time boxing them
| and applying some pressure on them to commit.
|
| An unlimited free trial falls into the same trap of customers
| leaving until they're "ready" to integrate, time boxing it sort
| of forces them to commit to the integration at some point.
| ezekg wrote:
| I don't think it would make a considerable difference. Not
| mentioned in the post, but I have a limited unlimited free
| trial. Taking into account the usage limits, it's not useful
| for a production deployment so it applies pressure once
| integrated. That way I only apply pressure to those that
| actually integrated.
|
| If I were to do a timed trial again, it'd apply pressure to
| evaluate and plan the integration _right now_ , and the product
| may not even be at the stage where they're ready to do that yet
| i.e. still in dev. This needlessly applies friction, which I
| want to avoid doing until they're ready.
| mason55 wrote:
| I could certainly be abnormal, but I'm much more likely to sign
| up for something that has a real free tier. There's honestly
| very little difference to me between 60-day free trial and just
| having to pay from the start, I know that once I do the work to
| integrate then I'm committing to having to pay. At least for a
| startup with little revenue and little cash, 60 days is just
| too soon to commit to having to pay, unless it's like $10/mo.
|
| What's worked better for me is the "startup scholarship" that a
| lot of companies are doing now. A year is far enough away that
| we'll either be out of business or have the cash to pay, and I
| don't need to worry that I'm getting my money's worth by the
| time the 60-day trial ends.
|
| I'm a big fan of Posthog right now because they have both a
| generous free tier & a generous startup scholarship. I've moved
| a ton of stuff to their platform.
|
| A lot of it probably depends on your product though. If you're
| solving a very targeted problem then you might not be able to
| create a reasonable free tier. But a lot of B2B tech stuff is
| like... sure you can charge a bunch of users $5 apiece, but you
| risk missing the signup of the one user that was going to pay
| you $10k. Anything with usage-based pricing is going to have
| Pareto distributed revenue and you need to do everything you
| can to make sure you're capturing those customers on the tail.
| ezekg wrote:
| > There's honestly very little difference to me between
| 60-day free trial and just having to pay from the start, I
| know that once I do the work to integrate then I'm committing
| to having to pay.
|
| Yep. That's the problem with timed free trials. It applies
| pressure to sign up only within your magical goldilocks
| timeframe, otherwise you'll likely bounce because you're not
| ready to start your 14/30/41/60/etc. day eval.
| ang_cire wrote:
| It seems obvious that the conversion rate was higher among people
| who wanted extensions, because the people who don't are the ones
| who already decided not to use it; rarely are people going to
| turn down more free time to use something and rush to ask to be
| allowed to pay for it (though it does happen- I've been part of
| procurements that were being rushed to use an existing FY budget,
| for instance).
|
| Another thing you need to work out, imo, is what level of
| *feature use* in your application best maps to conversions, and
| from there, how can you improve the likelihood of people seeing
| the benefits of that feature use.
|
| As an example, my current company's app can be used with or
| without agent deployments, and we saw that trials that deployed
| agents- even just one-off ones in lab envs- converted at a far
| higher rate than non-agent trials.
|
| So we worked to lower the perceived barrier of entry that agent
| deployments posed, which meant more people seeing the increased
| usefulness they provided, which meant more conversions.
| Sharlin wrote:
| > It seems obvious that the conversion rate was higher among
| people who wanted extensions, because the people who don't are
| the ones who already decided not to use it
|
| Yeah, exactly! Those two groups are not the same, there's an
| obvious selection effect there.
| 7thaccount wrote:
| Even 30 days is useless for me with my schedule on some items.
| Some of the optimization solvers are annoying that way if you're
| trying to get a proof of concept together to get management buy-
| in, but it'll take a lot of development to get there. You can use
| one of the generic libraries that abstracts away the solver
| (where you can plug most vendors in) and start with an open
| source option, but it's an annoying approach if I think there's a
| strong chance we'll end up with a particular vendor as I'd want
| to use their native API and avoid the additional abstraction
| layer.
|
| I totally understand why it makes sense to the business, it's
| just hard to work it in to my schedule.
|
| Another thing for these companies to think about is a potential
| customer is investing their own time in learning your product.
| They may not act on it right away, but I've been in situations
| where we had an "oh crap" moment and I was able to say go get
| product X, I know it works on our data sets and already have
| example scripts for how we can use it and the vendor indicated a
| price of Y last year which is like 1/5 the cost this other vendor
| just quoted you to start implementing this from scratch. Allowing
| employees some creativity to scratch that itch seems to
| constantly pay off in my experience as long as they're still
| being successful at their main job.
| kuschkufan wrote:
| OT, but your HTML is not valid. <!DOCTYPE> is declared twice.
| mouzogu wrote:
| a software i paid for 10 years ago recently got bought by another
| company.
|
| they immediately added bs "features" like dark theme, changed to
| subscription model with 1 year sub price 3x what i paid to buy it
| outright, and reduced trial from 30 to 12 days
|
| piracy is the only true form of digital ownership.
| cableshaft wrote:
| Me and Adobe right there.
|
| They want me to pay a subscription, but as long as Windows will
| still open CS6, I'll keep using it. It still gets the job done
| for me, even though I wouldn't mind some of the newer features
| (some of my annoyances I know they've improved in the new
| version) and probably would have paid for an upgrade by now if
| it wasn't all subscription models now.
|
| And hopefully by the time it stops working, another non-
| subscription option for Illustrator that I don't hate will be
| available.
| EricE wrote:
| A great list of alternatives has been floating around on
| Twitter after their AI debacle:
| https://twitter.com/WayneTalbot/status/1786703024330588237
|
| I really enjoy the Affinity tools; they more than meet my
| modest requirements.
| sib wrote:
| >> I really enjoy the Affinity tools; they more than meet
| my modest requirements.
|
| https://affinity.serif.com/en-us/press/newsroom/canva-
| press-...
| cableshaft wrote:
| I didn't like Affinity or Inkscape when I tried them (I
| even bought Affinity on a sale in order to try it, so I own
| it). Affinity also had issues importing my CS6 Illustrator
| files, IIRC, and since I have hundreds of those for various
| board game designs of mine that I still go back to and
| rework when I have a new idea for them, the fact that it
| couldn't play nice with them made it pretty much a
| nonstarter.
|
| It's been a while since I've used Inkscape, but I remember
| it feeling clunky and buggy for me, and I had difficulty
| getting into the workflow.
|
| I'm sure I could probably force myself to get used to, and
| probably enjoy alternatives, but the more I invest in these
| proprietary alternatives, the harder it will be to shift
| anything back to Illustrator if I need to, especially since
| I don't think any of them bother to output to a CS6
| friendly file format anymore, so I can shift to them, but I
| can't easily shift out of them.
|
| And at this point Illustrator CS6 is just dead simple for
| me, I don't have to think about where anything is, I know
| exactly what I need to do for like 98% of what I want to do
| on it, and most of it is muscle memory, I can whip up some
| cards in a few hours while watching TV shows in the
| background.
|
| It's going to take something significant (like it no longer
| working) to motivate me enough to upgrade. I know I'm
| playing with fire a bit, since these files are getting more
| and more out of date, and may not import nicely into even
| the subscription Adobe Illustrator at some point, but I
| already have too much other shit I have to learn all the
| time for my day job, I don't have much left outside of that
| (maybe eventually I will. I am starting to learn Logic Pro
| and Ableton Live for making music finally, and for the
| longest time I only used FLStudio).
|
| That's a cool graphic though. I'll download it for future
| reference. Also it'll be easier for me to convert for other
| Adobe products, like I mostly use Paint.NET instead of
| Photoshop nowadays, for example. Illustrator is the main
| one I feel I have to stick with. Also Flash, since it
| doesn't exist in any newer ones (I used to make Flash
| games, so if I want to open those FLA files again, I need
| it).
| egberts1 wrote:
| Two months and they're hooked ... or not.
| ProllyInfamous wrote:
| I'd say this is about correct... my new Toyota came with 3
| months of free satelite radio, and it was at about 2 months
| casual usage that I decided "I'm going to actually sign up"
| [after having enough time to explore multiple channels].
|
| Had it only been "1 month free" I would not have explored
| enough to sign up.
| glonq wrote:
| Just last week, I abandoned a 7-day trial of some project
| management software because it was not enough time for me to feel
| comfy with it. Would have preferred a week or two more, even if
| features were somehow nerfed (watermarks, etc).
| batterylow wrote:
| I run a plotting/visualization library.
|
| Instead of a time-limited trial, we have just one of the plot
| types (Sankey) freely available indefinitely
| (https://plotapi.com/page/sankey/).
|
| We tried a time-limited trial, and we just ended up with people
| re-registering new accounts every 2 weeks.
| semireg wrote:
| I develop barcode and label design software. My app is
| immediately usable after download, but it will print a watermark
| when not licensed. Users can start a 14 day free trial to remove
| the watermark. Since it's a desktop app, each trial is locked to
| that one computer. I can keep track of which computers register
| for a trial and limit the duration for subsequent re-
| registrations. It's all based on JWT.
| jt2190 wrote:
| The author does a really good job of describing the tension
| between the customer's readiness and the vendor's need to move
| leads through the pipeline as fast as possible:
|
| > What I was really asking potential customers to do was wait.
|
| > Wait until they're ready to start understanding the API.
|
| > Wait until they're ready to go through onboarding.
|
| > Wait until the PoC is planned.
|
| > ...
|
| > What ends up happening is that people get busy and they end up
| seeing that 14 day deadline, determine that they're not ready
| yet, so they bounce until they are ready, but then they never
| come back.
|
| > I decided that I needed to remove that friction. I wanted to
| capture these leads as soon as they decide Keygen may be the
| solution for them. So ultimately, I can start nurturing these
| leads.
|
| I'd love to hear more about what "nurturing" looks like.
| kennykning wrote:
| great post! off to calculate TTC for my company right now..
| dangus wrote:
| In B2B sales something that can happen with extension of free
| trials is that companies doing window shopping, doing competitive
| analysis, or who aren't motivated to find a solution to an
| immediate need (don't fit the ideal customer profile) and
| essentially don't intend to buy will do half-hearted integration
| and extend trials. It's a runaround which ends up costing your
| sales organization valuable time and effort.
|
| Usually it's just a matter of the implementers on the prospect
| side not prioritizing the effort.
|
| A free trial should usually be followed by a proof of value where
| both parties are committed to implementing the solution in a
| realistic way with the expectation of a signed contract if the
| proof of value delivers on the customer requirements.
|
| This could be something to be careful of if that applies to you.
| jessriedel wrote:
| > You may be thinking -- what does this have to do with time-to-
| convert?
|
| > We'll get there.
|
| Just FYI, I consider this tease-based writing to be reader-
| hostile, the prose equivalent of clickbait. It's the surest way
| to get me to quit reading.
| ropejumper wrote:
| Have you read the article? It's not clickbait, it literally
| goes on to explain it, and it's only a couple paragraphs. I
| honestly don't see the issue, and the fact that the author
| acknowledged a potential question is IMO a good thing.
| jessriedel wrote:
| If this were really the justification, there are almost
| always better ways to do it. ("If you're wondering about X,
| see section N". Or just link to it.)
|
| Like other dark patterns, there times when this sort of thing
| can make sense, but in practice it's usually done
| (consciously or not) to get the reader to read more than they
| would otherwise.
| ahmeneeroe-v2 wrote:
| I don't think so. The author is acknowledging that there is a
| very obvious question they need to answer and doesn't want to
| leave the reader in doubt about whether they will answer it,
| but wants to finish making a different point first. It's almost
| the opposite of reader-hostile.
| Gbox4 wrote:
| I disagree. I feel like this is something they teach you to do
| in composition classes - i.e. a hook.
| jessriedel wrote:
| There are all sorts of things taught in composition class
| that do not promote learning/understanding
| alkonaut wrote:
| Don't do limited time trials. Please. A limited trial means I'm
| going to have a worse dev experience with deadlines, activation
| or loss of functionality. Having a time limited trial or even a
| requirement to submit an email in order to try something is a big
| turnoff when evaluating a product.
|
| Just make the product free for non commercial use (including a
| trial in a commercial setting). If I need support or want to buy
| something _please_ let me contact support or sales. I don't want
| an automated email from Jeff at Randomcorp asking me how my trial
| is going. If a trial has to take 30 days or 365, just let me
| finish.
| aidenn0 wrote:
| I wonder how a free-tier compares to a 6- or 12-month free trial
| period.
| 999900000999 wrote:
| Rate limit free users.
|
| If I sign up on Monday, I might not even look at the API docs
| until Friday. Assume the week after that I personally like it, if
| I'm at a bigger company I'm probably going to spend a month or
| two just getting approval to expense it.
| ezekg wrote:
| Agreed. I have usage limits (e.g. 100 active users), as well as
| a hard limit of 2k API requests a day for the free tier. This
| provides freedom i.r.t. PoCs but restricts production usage.
| liotier wrote:
| And if the user indefinitely uses the service within the free
| tier, they are not the target customer anyway - so count the
| infinitesimal usage as evangelization !
| 0xbadcafebee wrote:
| Hey SaaS. Here's what I want from you (re: sign-ups):
|
| 1. Show me your price, with multiple pricing tiers. The more
| tiers you have, the more likely I am going to pick one of them,
| because I will think "well this _lower_ tier is quite the deal
| compared to the higher tiers! ". If I am an Enterprise customer,
| I will disregard you as an option if I can't see a price. Don't
| even show me the tier at all if you aren't going to show me your
| price. I get immediately incensed when I see that "Contact us for
| pricing!" bullshit, because I know how much bullshit I am in for
| if I just want to get a quote, so I look for somebody else. I
| want to use your product _right now_. But I 'm not going to use
| it if I think it will be painful to work with your company, or
| that you might have exorbitant pricing, or you're just looking
| for whales. Don't make me discount you.
|
| 2. Let me use your product, immediately. Let me run it from my
| laptop immediately. Let me spin up a PoC. Show me your complete
| reference docs immediately. Show me a toy implementation
| w/source. I want to know if this will [eventually] give me what I
| want, within 15 minutes. Do that and you will already have gone
| above and beyond 95% of SaaS (in my mind).
|
| 3. Let me have gradient pricing. Let me sign up right away and
| start using your product for $0, for 5 users. Send me an e-mail
| when I have 7 users, informing me that I have 30 days to either
| reduce the number of users to 5, or it will automatically upgrade
| my account and charge me more (or make me confirm, or whatever).
| Same for the next tier, etc. (or 'pre-purchase' discounts vs 'on-
| demand' overage cost, etc) This gives me flexibility: I know our
| workflows won't just stop working when we hit a limit, and I can
| acquiesce to the new price or clean up old users.
|
| 4. Let me start using your product without a card on file.
| Sometimes it takes a while to find the right corporate person
| with the right corp card (if they even let me use a corp card,
| rather than invoicing). If you really need a card, give me 15-30
| days, and then pause my account if you have to. The point is to
| let me get "hooked" on your product without needing to figure out
| which card to use first. (It goes without saying that when the
| card expires or a charge doesn't go through, give me 30 days to
| resolve it, because usually the corp card has hit its limit)
| nlh wrote:
| So it's interesting. Everything you ask for here is something
| I, personally, as an independent wanna-get-my-hands-dirty nerd,
| would ask for too. I totally get where you're coming from.
|
| But the thing is - the reason large companies often don't give
| folks like you and me these things is becuase there are proven
| reasons to do the contrary that actually end up making them
| more money. It sucks, but it's reality.
|
| 1. "Call us" pricing works because for big enterprise deals
| (4-7+ figures), there's often some serious negotiation involved
| and if you just show a sticker price up front, you risk a)
| scaring the buyer because the price is too high, b) losing the
| buyer because your competitor will just negotiate a better
| price than your listed price or b) leave yourself no room to
| negotiate if you really put your best price on the website.
|
| 2. Offering immediate free trials where you can jump in right
| away is the ideal world for nerds -- again, I love it
| personally. But software is often complex, and a guided
| demo/implementation is often the best path to make sure your
| buyers are actually successful. Otherwise you risk a lot of
| folks who sign up, jump in, have no idea what they're doing,
| and then abandon the trial immediately and go to a competitor
| who held their hand.
|
| 3. "Let me sign up right away and start using your product for
| $0..." If only offering Freemium were so simple. You will
| immediately have to deal with porn (it's always porn - and
| often kiddie porn. These people will figure out incredibly
| creative ways to use your SaaS product to host illegal content
| one way or another), spam, fraud, customer service issues, etc.
| There are many valid reasons to offer Freemium. There are many
| valid reasons not to do so. It's just not so simple.
|
| 4. Again, think about the flip side here. Lower friction to
| sign-ups without a card, but SO much hassle when it comes time
| to pay -- now you have to nag, bug, etc. to get payment, and
| then you have to delete accounts that are dormant. And you have
| much lower buying intent signals, etc. etc. etc.
|
| I wish the world of software catered to folks like us, but I
| fully and completely understand why it doesn't.
| levocardia wrote:
| Indeed many of these "complaints" are explicitly designed to
| filter out high-maintenance, needy, and stingy customers,
| leaving you with the people who are more than happy to say
| "shut up and take my money."
| ShakataGaNai wrote:
| > 1. "Call us" pricing works because for big enterprise deals
| (4-7+ figures), there's often some serious negotiation
| involved and if you just show a sticker price up front, you
| risk a) scaring the buyer because the price is too high, b)
| losing the buyer because your competitor will just negotiate
| a better price than your listed price or b) leave yourself no
| room to negotiate if you really put your best price on the
| website.
|
| I'd disagree and say this can go either way. As an enterprise
| buyer I know both MY budget and that all numbers are
| negotiable - to some extent. If you show me that this product
| costs $100k and my budget is $80k, I'll still talk to you.
| But if you list $100k and all I've got is $25k for the
| budget, yes, I'm going elsewhere.
|
| Now you might argue "We can make something work" I'm
| concerned. You'll do 80% off deal? Clearly you don't think
| your product is worth what you list so... now I don't think
| so either. And the "But We've got a tier for that" then list
| it.
|
| My time is way valuable to me. I do not want to go through 3
| screening calls, a shit ton of hoops, and a 2 week wait...
| just to find out that your product is way too expensive for
| my budget. Especially when getting into those sales calls
| where the reps wanna play coy and say "Well whats your
| budget" or "Well it really depends, we want to get into a POC
| bla bla bla to understand your useless before providing a
| pricing". Ain't no one got time for that shit. Give me the
| MSRP up front (with the understanding that a deal may be
| reachable if it's a little much) or I'm walking.
|
| Keep in mind that when I'm pricing your product I'm probably
| pricing 3 to 5 others. There is literally not enough hours
| left in my life to give each and every vendor a 5 hours of
| time in order to get a price.
|
| Fortunately the world is shifting. You know who's pricing is
| available on their website? Salesforce. Okta. OneLogin. Ping.
| Slack. Github. Gitlab. AWS. Google. Microsoft (for some).
| Elastic. Tailscale. Adobe. Databricks. Datadog. Cloudflare.
| Zoom. ... The list goes on. In other words there are a lot of
| companies out there with their prices available on their
| website right this second. Sure, almost everyone of them has
| a "Enterprise call us for pricing" option and that's fine, as
| long as you've got something for me to start with.
|
| If you're a software vendor and don't have some prices to
| start with, you're at a major disadvantage. Because your
| competitors often do. And price is not the only thing buyers
| are looking for. If it was, Okta would have no business. You
| can look at their prices and OneLogin and Ping's (and Azure
| AD and Google). The entire IAM/SSO space has their prices
| right out front and Okta is... the most expensive. Yet
| somehow they all still are selling.
| eszed wrote:
| You're dead on with all of this. To add to your point, the
| worst and most regrettable software product my company uses
| would have been immediately exposed as non-viable had I been
| allowed to get my hands dirty and run a couple of test cases.
| As it was, the sales-person "yada-yada'd" my technical
| questions (more fool me, yes, but I didn't know enough about
| their internals - the primary cause of our discontent stems
| from a _truly stupid_ database-design decision) and so I
| lacked the context to make an informed decision. (I 'm more
| experienced and more suspicious now; I don't _think_ I 'd
| make the same mistake again.) You can add borderline-
| fraudulent sales practice and avoiding discovery of truly bad
| products to the list.
| nickjj wrote:
| High pressure time offers that are only known after signing up
| kind of stink too.
|
| I've never used Uber in my life but I'll be traveling
| internationally next month for the first time so I figured it
| wouldn't hurt to install Uber now to get a feel for what the UI
| is like.
|
| As soon as I signed up Uber was like, hey we'll give you 50% off
| your 4th ride if you complete 3 rides within 14 days. I won't
| even be traveling by the time the offer runs out. All this does
| is make me feel like I made a mistake for signing up too early
| without knowing anything was going to happen.
| JonChesterfield wrote:
| On the bright side Uber now has the right country set for you.
| I signed up in Belgium and Uber is now convinced that's where I
| am based for all of time.
| zamadatix wrote:
| I had something similar once but editing "Location" in
| https://riders.uber.com/profile fixed it for me. YMMV
| zamadatix wrote:
| Uber goes nuts with offer notifications until you find the page
| to turn ALL of them off (quite a few, and broken out by
| category like Uber Eats vs Uber). The overall app is good
| enough, it's just a unfortunately spammy.
|
| As a ridiculous example: I took an Uber from an office to the
| Indianapolis airport then an Uber from the Dallas airport to a
| hotel for the night. As I'm winding down for the night I get a
| notification from Uber: "Need a ride back to
| ${indianapolisOffice}?".
| eszed wrote:
| Oh, thank you! I just turned all of those off, and am looking
| forward to fewer emails and push notifications.
| sct202 wrote:
| A company recently denied us a trial extension, even though they
| could tell we barely got to use their software by the time they
| got around to granting us trial licenses after a series of sales
| pitch meetings. We ended up signing with their competitor, who
| was patient and gave us a few free credits instead that we could
| work thru on our own pace.
|
| Both companies knew that we had been paying a different 3rd
| company quadruple either of their rates, so I was baffled that
| the first company would basically write us off so quickly when we
| were openly motivated to switch.
| mark242 wrote:
| On the contrary - any trial you offer is incorrect.
|
| "People won't know the value of my service if they can't use it!"
| means that you either aren't doing a good enough job showing them
| the value of your service up front, or you have an incorrect
| pricing model.
|
| Let's take Stripe as an example. It is absolutely free for you to
| create an account, browse the dashboard, read their API
| documentation, etc etc etc, but they take their cut of every
| single financial transaction you do on their platform. There's no
| trial - either you find value in Stripe's services, or you don't.
|
| Notion has a free tier for single user seats because that's their
| marketing plan. The moment you want to use Notion for what it's
| built for, team use, you're paying per user - again, there's no
| trial period there. Same for companies like Atlassian or IFTTT or
| Zapier or on and on and on.
|
| "You get our full service for X days for free, then you have to
| start paying" is incorrect for _all_ values of X. Either, "you
| have to pay to be a user of myproduct.com" or "you can be a free
| user of myproduct.com but once you get to a level where you're
| serious about using the product, you have to pay" is the correct
| strategy.
| naltroc wrote:
| OP provides data on time-to-convert at various timescales. It
| looks like it's working for them.
| mark242 wrote:
| Yes, I read the article. 90 percent of their signups are
| within 130 days. That's not a great funnel.
|
| I'd be curious to see the breakdown of SaaS vs self-hosted
| customers.
|
| Again, imagine what the funnel would look like if the page
| simply said, "First 100 license keys are free forever. Then
| pay $0.005 per license key issued."
|
| That's a very, very easy opex cost for a developer (and a
| finance department!) to understand.
|
| Right now you can get 50 "ALU"s for free per month but the
| page doesn't say that at all on first glance; you have to
| move your slider to the left in order to get that offer.
| Instead there's so much complexity on that page. API requests
| per day. Number of licenses. "Number of policies" (whatever
| that means?!?). Number of products.
|
| Devs, please please please simplify.
| mvkel wrote:
| I think the opposite. The trial length is simply a proxy for how
| long it takes the prospect to actually have the meeting to make
| the decision. By making it 41 days instead of 14, prospects will
| sign up and then wait 35 days before logging in a second time to
| -maybe- trial it. I'll get to that later.
|
| That said, any-day trials ain't gonna cut it.
|
| It's not about the number of days, it's that a trial is offered
| at all.
|
| Software customers these days (especially B2Bs) have an internal
| list of hurdles that prevent them from signing up at all.
| Methodically remove each hurdle, and at the end there is nothing
| left to do but buy, or ghost.
|
| A trial is a hurdle to be jumped.
|
| I would bet that the number of paying customers who actually
| -trialed the software- is 20%.
|
| Why?
|
| It takes time, effort, resources to set things up in order to
| trial them. To spend those resources means the purchase already
| needs to be approved.
|
| TLDR saying that you offer a trial at all, for any length of
| time, is objection handling, not conversion optimization.
|
| I'd bet you could say you offer a 3 day trial and see zero change
| to the funnel %s.
|
| The story in the post also doesn't seem to address the problem
| (lowering TTC):
|
| > paid sign ups also increased, with conversion rate staying
| steady, but now with no manual work.
|
| Ok, but did TTC (the problem) go down, or up?
| crazygringo wrote:
| Even for consumer software, the common 7/14/30-day free trials
| are bizarre.
|
| My general use case is to download and test software to use it _a
| single time_ , for some random new task I only need that day. To
| use the software for 5 minutes.
|
| Then three months later, oh it turns out I need to do that thing
| again, or test it out in a new way. It says the trial has
| expired, even though I only used it for 5 minutes. And I'm not
| going to pay $$$ just to use it for another 5 minutes and
| possibly never again.
|
| I don't understand why x-day free trials haven't been replaced
| with _usage-based_ free trials. E.g. whether it 's exporting a
| final result 20 times, or running a filter 50 times, or
| processing 100 input files, or whatever metric makes sense for
| the particular product. Or heck, keep it a 14-day free trial but
| count the days _individually_ -- so if I use it on May 2 and then
| on May 15, that 's only two days.
|
| The idea that, as a consumer, I'm going to sit down and fully
| evaluate a piece of software over the course of 7/14/30
| consecutive days to then make a purchasing decision is _bizarre_.
| groestl wrote:
| Browser games, they've nailed it. So if you're talking about
| gamification: this is what you ought to be talking about.
| tithe wrote:
| > Browser games, they've nailed it.
|
| Could you elaborate how?
|
| Admittedly I don't play browser games, but is it as the
| parent comment says, trials in browser games are usage-based?
| wmil wrote:
| It'd be pretty hilarious if GoLand switched to a mobile
| pricing model where the IDE is free... But you have to use
| build gems to run things. You get a fixed number of build
| gems a week then you can buy more fro $9.99 or $19.99.
|
| Your debug gems would recharge after watching a short ad.
| renonce wrote:
| > I don't understand why x-day free trials haven't been
| replaced with usage-based free trials
|
| They want you to pay for it, don't they?
|
| What I do think would be worth it is micropayments, so for each
| usage you will pay just $0.2 or so. Unfortunately such a
| payment scheme is not practical under current Visa/Mastercard
| system.
| unilynx wrote:
| Or under any realistic payment system that end users would
| want to use
|
| No offense, but micropayments have to be the most often
| suggested non-solution to any problem since the "402 Payment
| required" code was added to the HTTP spec
| ericd wrote:
| Idk, I'd pretty happily pay $0.50 to use an infrequently
| used utility once, if it was totally effortless. But
| everything wants like $20-30, or even worse, to lock me
| into some monthly subscription.
| kulahan wrote:
| That level of effort is something I think matters a lot.
| If you could make it incredibly easy for people to spend
| $1-2 (and no more), you could get a TON of money out of
| people. I dunno how you'd solve that major structural
| issue, but if you could, it sounds like a goldmine. If
| nothing else, microtransactions in software would
| probably explode more than they already have.
| ska wrote:
| I think hypothetical/magic micropayments that just work(TM)
| actually solve lots of problems. The problem is with the
| "realistic" part, which is why it always comes up.
| Yeroc wrote:
| Sadly, the only micropayments implementation we have is ad-
| supported apps. It's essentially micropayments. Albeit a very
| annoying implementation!
| p_l wrote:
| Scrivener has an interesting pattern where they offer 30 day
| trial - _but they only count the days you use the software_.
|
| So if you first play with interface for few days, but end up
| not attempting to write more of your great next novel for two
| months because you were swamped with real life, you can come
| back and there's still most of the trial left.
| twodave wrote:
| BeyondCompare does this too, and even though I've purchased a
| license I have some machines where I haven't activated it in
| almost a year of infrequent usage :)
| realityfactchex wrote:
| Yes, it's really nice IMO that BeyondCompare has this
| model.
|
| After 30 days of ACTUALLY using it (days which are
| sometimes few and far between, and sometimes more closely
| spaced) is really a point at which, yes, it's justified to
| purchase, showing that it has been "the tool of choice" so
| many times, and likely to be so into the foreseeable near
| to mid future, too.
|
| The trial is critical to a) proving that it does the useful
| things, b) determining that that it does said specific
| things better than the alternatives for some relevant
| definition of better, and c) giving enough of a chance to
| really learn it well enough to make an informed decision.
|
| The free period builds tremendous goodwill, and is a really
| sane and "nice to the community" choice for a tool that
| might get used occasionally. It shows the confidence that
| the market really is there for it in general. People who
| can/do reap value from it on an ongoing basis will convert.
| tppiotrowski wrote:
| I think most consumers would agree that this is the fairest
| model. If I pay for 30 days of Netflix, only charge me for
| the days I watch so then I feel like I'm using my entire
| purchase.
|
| The current SaaS model is like going to the store and you can
| only buy 5 gallons of butter or milk and you have one week to
| use it. It "feels" like most of your money is being "wasted".
| At least that's my perception.
| crazygringo wrote:
| _Exactly_. Great to hear that at least one company does this.
| It makes perfect sense, because it matches how unpredictable
| people 's lives can be.
|
| Just because you offer a 7 day trial and I had time today to
| try it out a bit, doesn't mean I'll necessarily have any time
| at all over the next 6 days to finish evaluating it. Life and
| other work priorities happen.
| citruscomputing wrote:
| Mp3tag for Mac (https://mp3tag.app/) does the same - great
| piece of software, I've used it 6 times and have one day of
| trial left :)
| XCSme wrote:
| Well, I sell a website analytics platform, so 14 days are
| needed for you to gather data and get meaningful insights. Even
| if you forget about it, and come later, you can still see the
| data and test the features.
|
| Also, the app is self-hosted, so part of the trial benefit is
| that users can test the installation process, which is usually
| the biggest push-back against self-hosting.
| unilynx wrote:
| Would it be possible to always offer the last 14 days of
| stats, but only allow a login/access to that data eg 3 or 7
| times ?
|
| I wonder if that might fit the average pattern of a casual
| stats user a bit better (only actually checking the data when
| asked by the manager) to keep them hooked for a much longer
| 'wall clock' time and get them to eventually convert (I've
| been depending on this for half a year now)
| ericd wrote:
| Yeah, freemium with a free tier that's useful for casual
| use converts me way more often than time-based trials.
| XCSme wrote:
| Hmm, but what would make you upgrade from the free tier
| to premium? Because you still can't try the premium
| features. Wouldn't I still need to provide a trial for
| the premium features, for you to decide whether they are
| worth upgrading?
| XCSme wrote:
| That's a good idea and, in theory, I could implement a lot
| of different models.
|
| In practice, because it's self-hosted, "cracking" might be
| an issue. Customers might edit the files that affect the
| retention, for example. Maybe most customers won't do it,
| but I don't know. This also feels a bit like I would have
| to implement some "DRM", which I really don't want.
|
| Now that you mentioned it, maybe a better trial would be a
| freemium model, where I can serve a different version for
| free that only has some features. The problem with this, is
| that the customer won't get all the benefits of using the
| product, so they might not like it enough to upgrade to the
| full version.
|
| It's an analytics platform, so I could offer just basic
| stats for free and for premium all the other features
| (segments, heatmaps, recordings, A/B tests, AI integration,
| etc.). This could work as a good marketing technique for
| the top of the funnel, but then customers would still
| probably want to trial the pro features, so I am stuck with
| the same problem as before.
| TheGRS wrote:
| Your example just demonstrates the usefulness of a time-based
| trial. You personally might not come back but the next customer
| might.
|
| I know everyone complains about Adobe's switch to subscription,
| but it would fit the model you'd want where you could pay for a
| month of usage and then turn it back off.
| raincole wrote:
| > Your example just demonstrates the usefulness of a time-
| based trial. You personally might not come back but the next
| customer might.
|
| Yes, exactly.
|
| The parent comment says they are not going to pay to use it
| for another 5 minutes. So if it were usage-based, would they
| pay to use it for the 21st times, after they run out the 20
| free uses?
|
| And they only use it once per _three months_. So the 21st use
| is 5 years later. Will the software still be maintined by the
| time? Will the dev still exist? Will the problem itself still
| exist?
| crazygringo wrote:
| I _would_ pay for it by the 21st time.
|
| That was my point. If I'm using something for only the 2nd
| time, then statistically it's very unknown whether I'll
| ever use a 3rd time. If I paid for it now, there's a good
| chance I'd be throwing away my money.
|
| Whereas if I've used something 20 times, then it's
| _extremely_ likely I 'll be using it another 20, 50, 100,
| or 1,000 times. It's clearly worth paying for after 20
| times.
| Aurornis wrote:
| > I would pay for it by the 21st time.
|
| In your example above (needing it every 3 months) it
| would take over 5 years to reach that point.
|
| I'm going to guess that within those 5 years it's likely
| that the developer would have released a new major
| release (with a new trial period), or that you would have
| reinstalled your OS (resetting the trial timer), or that
| you would have gotten a new computer...
|
| In other words, you'd never pay for the software.
| dijksterhuis wrote:
| You may be failing to see the woods for the trees. Dunno,
| not OP.
|
| > I would pay for it *by* the 21st time.
|
| By the 21st time != the 21st time.
|
| By the 21st time == at some point prior to the 21st time.
| Possibly the 5th or 6th time. Maybe the 10th time. Maybe
| the 3rd time.
| crazygringo wrote:
| > _In your example above (needing it every 3 months) it
| would take over 5 years to reach that point._
|
| That wasn't my example. It was 3 months between the first
| and second times.
|
| In my experience, your need for a tool often increases
| gradually. You have a one-off project that needs a tool
| briefly, then a couple of projects a few months later you
| need to try it more, then it becomes a regular thing.
|
| It's pretty rare that I go from never needing a tool to
| needing it constantly as an instant switch. Which is the
| only scenario where 7/14/30-day trials make sense.
| freeone3000 wrote:
| Except Adobe doesn't let you do that, you pay for an entire
| year month-by-month; cancelling early still leaves you with a
| bill.
| jkaplowitz wrote:
| Most of their subscriptions are available in a true month-
| to-month plan with cancellation at any time without a fee.
| But they charge a lot more for that plan. For example,
| $89.99 for month-to-month vs $59.99 for monthly payments
| toward an annual plan. Still, it's the cheaper and better
| option if you're only using it for a few months of the
| year.
| Spooky23 wrote:
| Adobe requires annual commit _and_ true up!
|
| Even with large relationships, they refuse to provide
| utilization metrics. So our team has to implement obnoxious
| processes to validate your use, or pay 15-25% more than we
| need to.
| jkaplowitz wrote:
| What you say is probably true for their enterprise deals,
| but most of their retail plans do offer true month-to-month
| options for less than double the monthly price of the
| annual commitment. It's a good option when one is only
| using it for a few months of the year.
| crazygringo wrote:
| > _You personally might not come back but the next customer
| might._
|
| Then that's a terrible business model.
|
| As a business, you want _both_ customers to come back.
|
| If a contiguous time-based trial model results in losing half
| your potential customers, while a usage-based trial model
| results in keeping all potential customers, then the
| contiguous time-based trial is objectively terrible.
|
| So it doesn't demonstrate the usefulness at all.
| TheGRS wrote:
| I'm also assuming OP didn't really intend to pay if they're
| coming to a tool that they'll use for 5 minutes. They don't
| see the value in paying, I'm just reading between the lines
| there.
|
| Maybe its still better to let them get a long free trial so
| they tell their friends about it, I dunno. Not a marketer,
| but it struck me as kind of disingenuous that if you came
| back to a tool after 3 months where you know you need to
| use it, they still don't want to pay.
| abcd_f wrote:
| Usage-based trials are much harder to enforce reliably.
| crazygringo wrote:
| I don't see why.
|
| A time-based trial records the date you started to use it
| somewhere.
|
| A usage-based trial records the number of times you've done
| something somewhere.
|
| I can't see why there would be any difference in reliability.
| The mechanism of recording and checking some value is
| identical.
| actuallyalys wrote:
| I think I have seen this model before, in the days of
| shareware. Offhand, I don't remember the name of the tool.
|
| A downside of this is that if you don't choose the right
| metric, people might burn through a lot of their uses due to
| mistakes. Like, to use your input files example, imagine
| someone accidentally selects a huge directory with more than
| 100 files and then end up with no free uses left.
|
| Some of this also comes down to overall UX design too, of
| course.
| YetAnotherNick wrote:
| If you "need" to use for the second time, it is lost revenue to
| cover that in free trial. Free trial are to give uninterested
| user interest in the product. If the need is already there,
| free trial can only make the product impression worse.
| wouldbecouldbe wrote:
| It's not bizarre, it's a common pattern that people understand
| and easy to implement. Most people will accept it for that
| reason even if it's not ideal.
|
| I have a lower tier that users can move to which is an
| effective filter to see who really wants to move forward, since
| our set up & initial support costs are relatively high also on
| trials. So that works well, even if we make a loss on smaller
| tiers it's a sign of commitment.
| zamadatix wrote:
| On the flip side (for the company, not the consumer) if you've
| come back to the tool 3 months later you're already mentally
| invested in learning the tool, know it works, and remembered
| it. Either that'll be a paying customer or it won't, giving
| them 100 input files doesn't really guarantee a sale 7 years
| from now (or whenever it is they run out).
|
| I.e. too short to actually be able to try it is a problem. How
| long "too short" is varies a lot based on what it is you're
| selling. Too short to be able to try multiple times may
| actually be a positive for total sales though, particularly in
| the consumer software space. As always the answer is "test and
| see what changes your sales" but that not much does it this way
| is more likely a hint it doesn't execute well with most models
| rather than nobody is trying it.
| crazygringo wrote:
| > _you 're already mentally invested in learning the tool,
| know it works, and remembered it._
|
| Not really. In my experience, I learned only a tiny
| percentage of the tool -- like how to run a noise reduction
| filter and nothing else. I know that one thing worked the one
| time for that one file, but not for other files with
| different types of noise. And I didn't even remember it -- I
| googled "noise reduction software" again, discovered the top
| link was purple, and only then remembered I'd already
| installed it on my system and forgotten its name. I started
| it up and it says I can't use it anymore because the trial
| expired.
|
| I might have a whole bunch of clips I need to noise reduce
| now, maybe it's going to become a regular thing at this
| point, but I can only test with competitors' software now...
| j45 wrote:
| Paying to keep the tool running for the few moments you need
| can be extremely expensive to pay for those moments only.
|
| Often it's an investment in your life to free up time. You can
| always get and earn more money, but it's impossible to add more
| time to your life.
|
| I agree not everything has to be a SaaS though, some are better
| as usage based, or a basic fee plus usage/overage.
| jahewson wrote:
| One reason not to do that is the sales and marketing lead time.
| Every time marketing changes something there's a 2 week lag
| before they can measure the conversion impact. With your usage-
| based trial concept that lag time becomes indefinite.
| filmgirlcw wrote:
| But to push back, if you're talking about a 5 minute task, that
| you're using once every few months, a free trial timed the way
| you are asking, might mean you never end up needing to purchase
| a license. I understand that that is useful for you, but that
| isn't exactly good for someone trying to sell a piece of
| software. (I understand you also gave usage based examples, but
| even in those scenarios (which require additional work to code
| for trial versions, versus a pure time-lock), there is always
| going to be someone who says "5 saves isn't enough" or whatever
| the metric is).
|
| > The idea that, as a consumer, I'm going to sit down and fully
| evaluate a piece of software over the course of 7/14/30
| consecutive days to then make a purchasing decision is bizarre.
|
| Maybe it's my past life as a software reviewer (and current
| life as someone frequently asked about my assessment/opinion on
| apps), but for consumer software (SaaS, especially for business
| like what OP article is about, I think is different), I really
| don't think this is that bizarre.
|
| To me, a trial is really instructive because if I'm finding
| myself opening or using an app frequently during the trial,
| that's a good indicator I'll get value out of the application.
| Similarly, if I did a trial in January for one task, then came
| back to do that same task again in May and the trial is
| expired, it's a good way for me to evaluate if it makes sense
| for me to buy a license or not. There are some programs I use
| two or three times a year that I purchase because it is useful
| enough for that one task, but there are others that I use
| infrequently enough to try to seek out other options. A time-
| based trial, for me, is a good forcing function to determine if
| I'm actually going to use the program.
| asah wrote:
| IMHO some light users _should_ be free - niche users who don
| 't have significant budgets or would be a support burden.
| Others get enormous value in 5 minutes, have easy budgets for
| this category of software and should be paying.
|
| I wouldn't be quick to judge either way.
| kelnos wrote:
| It's a little weird to suggest that just because someone
| wants to use the product of someone else's work only for a
| short time, that use "should" be free.
| amflare wrote:
| If you are offering free samples of your product, you
| shouldn't get mad at the people who don't need your
| product for more.
| SR2Z wrote:
| I mean, it's not strange to think that the ideal state
| for software is "used as widely as possible while
| maximizing profit."
| thfuran wrote:
| That's definitely a strange ideal, to put it politely.
| Human welfare should be maximized instead.
| ska wrote:
| I think the context of "should" matters quite a bit here.
| For example the claim that everyone should have free
| access as if by right is quite different than the claim
| that as the producer of said software this is your best
| bet.
| hinkley wrote:
| I took a job working at a company that made a code
| obfuscator/minimizer in the days before CI/CD really existed.
| I knew a lot about Java internals so I thought this would be
| good. First day I got assigned instead to an embedded Java
| project.
|
| Why? They couldn't market the obfuscator, so they were
| winding it down. People didn't want a license for something
| they used for ten minutes four times a year.
|
| (We did later hire an intern to fix bugs in the obfuscator.
| The app was constrained to a specific JAR size, and those
| gave us enough headroom for about another dozen features. And
| I made a change late in the project that got me space for two
| more, via suffix sorting the constant pool instead of prefix
| sorting it).
| fuzzythinker wrote:
| That is exactly the point. As a producer of the said
| software, if that is the user's usage pattern, and there are
| enough regular users to sustain/pay for these users, then I
| won't want to charge them. Doing so means I either lose out
| on potential customers or they aren't going to be a true
| customer anyways.
| kmacdough wrote:
| Counter to your counter, a person using software 5-6 times
| over a few years is almost never going to become a paying
| customer. They'll just cut you out entirely. But odds are
| they know similar professionals and could be a major promoter
| to potential power-users. Chatting with a few coworkers, none
| of us can come up with a single example of letting a trial
| expire, only to pay for isolated uses later. We had quite a
| few examples of software we thought might be valueable, but
| weren't prepared to pay having run out our trials. Three of
| us are in this state for Copilot alone.
|
| It seems you're very focused on what people "oughta" pay for.
| But what matters is simply what people do pay for. You tell
| this story, but it seems very inconsistent with my experience
| or my understanding of pricing theory.
| kulahan wrote:
| "It's free advertising" is an argument I see a lot, but
| I've never seen the numbers to see how much that actually
| matters in the real world. Well, I guess I've seen some,
| but it's always from ad companies anyways.
| meiraleal wrote:
| The person using this argument never accepts free
| advertising as a payment option and this tells everything
| about the effectiveness of this strategy
| trogdor wrote:
| I own a media production company. We occasionally sell
| content to other media outlets. Early in our existence,
| we were routinely contacted by reporters asking for
| permission to use our content with credit to us. I used
| to respond by saying yes, but only if I could use some of
| their content, with credit to them. Obviously, they never
| agreed.
| plussed_reader wrote:
| When it comes to free advertising/exposure as
| compensation I think back to my early days on the Oregon
| Trail:
|
| You can die from exposure.
| filmgirlcw wrote:
| > It seems you're very focused on what people "oughta" pay
| for. But what matters is simply what people do pay for. You
| tell this story, but it seems very inconsistent with my
| experience or my understanding of pricing theory.
|
| I don't know who the "you" is referring to. All I said was
| that in my personal experience, there have been occasions
| (not frequent, but it has happened) where I'll buy a
| perpetual license to something for a task I use a few times
| a year. Because the $20 or whatever the license cost was
| worth the time I saved. In most cases, what I said was that
| if I didn't use a piece of software after the trial
| expired, that was a good forcing function to figure out if
| it was something I find value in or not. And in most cases,
| the answer is going to be "I don't need to buy this."
|
| I'm not at all focused on what people oughta pay for so I
| don't know where you are misreading this.
|
| I also said that for business and SaaS options like the OP
| article is about, things are completely different (your
| Copilot example). The comment I replied to was about
| consumer software trials and how they don't think time
| limits make sense. I happen to disagree.
| tylersmith wrote:
| > But to push back, if you're talking about a 5 minute task,
| that you're using once every few months, a free trial timed
| the way you are asking, might mean you never end up needing
| to purchase a license.
|
| That's why they want that model. Complaints like the GP's are
| just a thin veil over being too cheap to pay for the software
| they use. You can see it in the other responses to your
| comment.
| pierrebai wrote:
| The problem with this thinking is that you are creating
| dissatisfaction for 25 cents.
|
| Let's say, you sell your software as a single-version
| perpetual license. You sell it for 150$. A typical user uses
| it 8 hours a month. After a year, that's 96 hours. So they
| spend less than 2$ per hour (I'm rounding in the seller's
| favor.) So using it for 5 minutes, 1/12h, is less than 25
| cents. (Again rounding up in the seller's favor.)
|
| Is this about not giving away 25 cents?
|
| This is where SaaS wins over, but even there, the overhead,
| both for sellers and users, of managing payment for people
| who want to do one-shot work is never going to be worth it.
| meiraleal wrote:
| This scenario is akin to wanting an insurance payout for a
| stolen car after paying just the last month's premium
| jasonlotito wrote:
| > There are some programs I use two or three times a year
| that I purchase because it is useful enough for that one
| task, but there are others that I use infrequently enough to
| try to seek out other options.
|
| Flip that. I find most people do the second thing first. If
| what I'm doing in the software takes 5 minutes, chances are I
| can find something else out there that will do the same thing
| for free as well. Sometimes the same software lets you trial
| it again because it's been so long. And so all the additional
| features you'd review them for amount to nothing when I'm
| just using them to remove the background in my picture.
|
| But here is the bigger issue.
|
| > it's a good way for me to evaluate if it makes sense for me
| to buy a license or not
|
| It's a horrible way for me to evaluate licensing. Why?
| Because, I probably want to get on with whatever task should
| only take 5 minutes and do something else. I don't want to
| spend time evaluating licensing and determine the cost
| benefits analysis of this software purchase (which more and
| more tends toward a monthly/yearly fee).
|
| I want to do the 5 minute thing and move on, and I will spend
| more time searching for another free solution than pay.
|
| You want to get me to pay you? Make that 5 minutes showcase
| the things I did't know I needed.
|
| And yes, if you have the only thing that can do the thing I'm
| looking to do, sure. But, a monopoly isn't exactly what we
| are talking about here.
| Sarkie wrote:
| This is exactly why they need to charge.
| Aurornis wrote:
| > The idea that, as a consumer, I'm going to sit down and fully
| evaluate a piece of software over the course of 7/14/30
| consecutive days to then make a purchasing decision is bizarre.
|
| But that's exactly what you described yourself as doing. You
| downloaded the software, used it, found that it satisfied your
| needs, and were familiar enough with the software to recognize
| that you needed it again three months later.
|
| The real bizarre thing is that someone can blame the software
| provider for giving away free use of their software, or for
| "only" allowing them to use it for 30 days for free.
|
| Honestly, I don't understand what model would actually satisfy
| you while also leaving a window for the software developer to
| get paid. If someone gave you 14 separate days to run a trial
| and you utilized the software on the same 3 month schedule,
| you'd have over 3 years to "evaluate" the software without
| paying a dime.
|
| > The idea that, as a consumer, I'm going to sit down and fully
| evaluate a piece of software over the course of 7/14/30
| consecutive days to then make a purchasing decision is bizarre.
|
| I don't understand this complaint, either. You already used the
| software, saw that it solved your problems, and then knew it
| well enough to know that you needed it again 3 months later.
| What more do you want? A full year to think about it while it
| solves your problems?
|
| Would you prefer if the software was usable in "trial" mode
| indefinitely, but you couldn't actually output anything (save
| files, get non-watermarked output) until you purchased it?
| That's the only alternative I can think of that would help you
| try the software longer, but then you would be forced to pay on
| the very first use in your example above. That actually leaves
| you worse off, not better.
|
| This whole conversation reminds me of why it's so much easier
| to deal with B2B and Enterprise software: With cheap consumer
| software, you get people who will complain to the ends of the
| earth about your $20 software or jump through hoops to avoid
| paying less than the cost of a couple drinks to purchase
| software that clearly solves their needs.
| ericd wrote:
| The thing is, I often get called away from whatever I was
| trying to do, and just don't revisit it for a few weeks, a
| month. I opened the software, but never actually used it. I
| go back to it later, whoops, free trial expired. I think x
| free uses is a much better way to do it, and I as a software
| maker don't really feel like I need to charge someone who
| only needs my stuff once or twice, the marginal cost to me is
| 0. If they're getting professional value out of it, or it's a
| big part of their day to day for some other reason, then I
| think they should pay. They're much more likely to make
| demands of me if they're in that bucket, as well.
| Aurornis wrote:
| > and I as a software maker don't really feel like I need
| to charge someone who only needs my stuff once or twice
|
| A 14-day (or 7, or 30 day) trial is actually perfect for
| this situation.
|
| But you can't make everyone happy. If someone is starting
| the trial and then not using the software for a week or
| month, that's their mistake.
|
| There was a time when nagware software was popular: You got
| to use it for free, but it would nag you with a popup or
| delay every once in a while asking you to purchase it. You
| can still occasionally find software with this model, but
| most developers quickly learned that the more leeway you
| give the free trial users, the less likely they are to buy
| it.
| ericd wrote:
| You can say that it's their mistake, but people not using
| your software successfully is always a mix of blame for
| both parties.
|
| Yes, you can probably make more by adding more pressure
| than nagware did. But you're doing it at the expense of
| being pro-user. I do think it's reasonable to be less
| friendly than that, if it doesn't work for you.
|
| You can probably make even more than free trials by
| getting people into a monthly subscription, making it
| harder to cancel, and/or making it so it's easier to
| forget that they're being charged, etc. There are many
| ways to enrich yourself at the expense of others. And
| many companies seem to have justified each of these to
| themselves.
| crazygringo wrote:
| > _If someone is starting the trial and then not using
| the software for a week or month, that 's their mistake._
|
| No, that's your mistake as a software maker. User
| behavior is user behavior.
|
| If you're losing potential paying customers because you
| lock them out of the trial because they didn't come back
| to it for a week, it's _your_ sales that will suffer.
| felipellrocha wrote:
| This makes sense to me. To some people, nothing will be
| sufficient outside of free. The demand curve predicts this.
| What is weird is that they're talking as if the problem was
| with every company trying to get paid (paying the bills?
| that's for the weak), instead of just simply recognizing that
| their purchasing power is relatively low.
| crazygringo wrote:
| > _But that 's exactly what you described yourself as doing.
| You downloaded the software, used it, found that it satisfied
| your needs, and were familiar enough with the software to
| recognize that you needed it again three months later._
|
| That's not what happens. I download it, use some tiny part of
| it once (like the noise reduction filter of a full audio
| editing suite), forgot about it, googled noise reduction 3
| months later, discovered I'd already installed it 3 months
| ago, and now can't try it with a different file because the
| trial expired.
|
| > _The real bizarre thing is that someone can blame the
| software provider for giving away free use of their software,
| or for "only" allowing them to use it for 30 days for free._
|
| But they deserve the blame, because now I'm going to go
| download a different audio editing suite to try _their_ noise
| reduction instead. And if now I keep having to do noise
| reduction because it 's no longer a one-off thing, I'll
| purchase that competitor. Because the first piece of software
| stopped letting me try it out so I can't even compare
| anymore. Even though I'd only used it for 5 minutes.
|
| My whole point is that "30 days for free" is meaningless if I
| only use it for 5 minutes. It makes much more sense for
| trials to be usage-metered rather than contiguous calendar
| days.
| Dalewyn wrote:
| If you used the program once during the trial period then
| came back to it again for some reason or another after the
| trial expired, the trial worked exactly as intended: You
| want to use the program again, so it's asking you to pay
| up.
|
| I don't see the problem here other than _" I don't want to
| pay for software."_ which isn't the programmer's concern.
| If you don't want to pay, the programmer likewise couldn't
| give a damn if you can't use his program.
| meiraleal wrote:
| They lost nothing by you not using their free trial again
| tho you are the kind of user that we all try to avoid
| paulddraper wrote:
| > why it's so much easier to deal with B2B and Enterprise
| software: With cheap consumer software, you get people who
| will complain to the ends of the earth about your $20
| software or jump through hoops to avoid paying less than the
| cost of a couple drinks to purchase software that clearly
| solves their needs
|
| Someone will drop $20 on lunch from some place with no
| guarantees to its quality and think nothing of it.
|
| But asking the same amount for software requires a
| painstakingly thorough evaluation.
|
| ---
|
| Products like Gmail, Facebook, Dropbox etc have trained
| consumers that the normal price of software is $0.
| Spooky23 wrote:
| It's an annoying arguably dark pattern and easy to game.
|
| Buying behavior is a psychological concept driven by time and
| attention. A persons mental wallet is open for a limited period
| of time. The goal of the trial is a conversion to sale.
|
| The scenarios you describe are edge case-ish, and often times
| companies will accommodate them as edge cases.
| ghnws wrote:
| Depending on the product, your trial may cost the company a
| decent amount of money. For example audiobooks are rather
| expensive to stream (due to publisher pricing, not bandwidth).
| neilv wrote:
| IIUC, the user evaluated it sufficiently for that task, such
| that they wanted to use it repeatedly for that task, _but_ the
| software can do a lot more things, and they don 't want to pay
| the price for just that one feature they evaluated so far,
| before they evaluate the other features?
|
| If we're selling consumer software, and our expectation is that
| people might use it only rarely, and only need a fraction of
| the features, but get value out of it when they do... can we do
| free trials without this perception?
|
| Don't do free trials? Cripple the trial so that user can see
| what it can do, but user can't get the benefit they want? Break
| a big package/suite into many small tools sold separately, to
| avoid the perception of paying for more than you need or can
| evaluate? Pay per metered use? Renewable subscription tiers?
| kelnos wrote:
| So essentially what you're advocating for is a model where some
| percentage of users can use the software in some limited way,
| for free, possibly over the span of many months or even years,
| and the person who built it sees no revenue from that use at
| all? Sure, as the article describes, that's an unlimited-time
| free tier. But maybe the developer doesn't want to offer a free
| tier.
|
| > _The idea that, as a consumer, I 'm going to sit down and
| fully evaluate a piece of software over the course of 7/14/30
| consecutive days to then make a purchasing decision is
| bizarre._
|
| Except you _did_ do that, in your example. You evaluated it
| over the span of 5 minutes (you didn 't even need days or
| weeks), and then were apparently satisfied enough with it that
| you remembered it and came back to it months later to use it
| again.
|
| And then you balk at the idea that you should have to pay for
| something that you already know you get value out of. I find
| _that_ bizarre.
| dustincoates wrote:
| > I don't understand why x-day free trials haven't been
| replaced with usage-based free trials.
|
| The same reason that people complain about the weapons behavior
| in Breath of the Wild or why no one uses the fine china: a
| usage-based trial actually _discourages_ usage.
|
| As someone else said, Scrivener offers this. I downloaded it
| and wanted to give it a try, but I was always hesitant to fire
| it up. I always felt that if I did use it and realized five
| minutes in that today wasn't the day I was going to write a
| lot, then I had wasted one of my 30 days. People as a whole are
| loss adverse, and so it is with usage-based trials.
| meiraleal wrote:
| Weird proposition. In both cases you would pay for the second
| usage and the free trial just proved that you need their
| product and they definitely should not let you use it for free
| j-cheong wrote:
| >I don't understand why x-day free trials haven't been replaced
| with usage-based free trials.
|
| Hmm I would say usage-based free trials are problematic because
| a small company might only use it 10 times but an enterprise
| might need to run 10k files to fully trial the product. So what
| usage level would you set it at? If you go too high the small
| companies can be on a free trial for years, effectively a
| freemium model.
| paulddraper wrote:
| > The idea that, as a consumer, I'm going to sit down and fully
| evaluate a piece of software over the course of 7/14/30
| consecutive days to then make a purchasing decision is bizarre.
|
| As someone who has made and sold such software, no it is not
| bizarre.
|
| It's very effective.
| scosman wrote:
| "open, source-available"
|
| That punctuation is so critical; I read as "open source
| available" first time through. I also make "open, source-
| available" software (aka, source-available). Do folks like this
| presentation? Or good old "source-available"?
| abcd_f wrote:
| > _A fourteen-day free trial ain't gonna cut it_ ...
|
| ... for things that take longer than that to test. That 's rather
| obvious. There a lot of software that can be evaluated for fit in
| a couple of hours, especially of a desktop/installable variety.
| XCSme wrote:
| Ok, I sell self-hosted software with a one-time payment (no
| subscription). Isn't a 14 days trial enough? Would a 30-day trial
| do better? Or a 60 days one?
|
| So far, people who start using the trial usually convert, so
| lengthening the trial will likely only decrease this. What it
| could improve, is the number of customers who are willing to
| start using the trial, thinking 60-days is a lot of free usage.
| ezekg wrote:
| For Keygen EE, my enterprise self-hosted edition, I do a 30 day
| no-strings-attached-trial. So it's different for self-hosted
| software, yes.
| gnicholas wrote:
| Seems kind of like a submarine article. Without knowing what this
| product/service is, it's impossible to know whether a 14 day free
| trial is appropriate. I don't care to spend the time learning
| what it is, and without knowing that it's hard to tell if this
| advice is relevant to other types of products.
|
| I also found this data point to tend to indicate that this
| testing/experimentation was not especially rigorous:
|
| > _out those that did [ask for an extension] and those that didn
| 't, my conversion rate was higher when they did ask for one._
|
| My first thought was that there is selection bias among people
| who ask for an extension. People who are pretty sure it's not a
| useful tool for them aren't going to take the time to reach out.
| KaiMagnus wrote:
| Yeah, fully agree. Tried to get into Sketch (multiple) times
| actually via their 30 day trial. But I've repeatedly run out of
| time testing details and special cases next to the job, so Figma
| it is.
|
| For note taking tools it's also hard. You only get to know the
| tool and how well you can work with it only after you spend time
| with it and have some content in there. Hard to do in 14 days.
|
| So letting users evaluate the core part of your service without
| time limit makes sense and it's good to see a successful example
| of that.
| datarez wrote:
| >I added an unlimited trial, a.k.a. a free tier.
|
| >What happened next?
|
| >Overall sign ups increased
|
| Top of the funnel increase is great, but I would be keen to
| understand whether overall revenue went up. Sometimes free tier
| attract the wrong type of customers
| pseudosavant wrote:
| It is my experience that unless you have high variable costs, you
| should be far more worried about people adopting and using your
| product than you should be about giving too much away for free.
| siva7 wrote:
| It's bizarre how many people think that offering free trials
| doesn't cost the company real money. Especially with a SaaS your
| trial will be a real bill for someone else.
| g4zj wrote:
| The very sight of the word "trial" makes a bad impression on me.
| It puts me on the defensive. I'm immediately reminded that I'm
| being sold a product, rather than offered a solution.
|
| I stop thinking about the task I was working on, or what lead me
| to the product in the first place, and start worrying about the
| details of the trial.
|
| "Am I going to need to enter credit card information to start the
| trial?"
|
| "Will any images I create be watermarked unless I pay a premium?"
|
| "Are the features I actually need even available within the
| trial, and are they actually useful during that time?"
|
| I don't want a free trial of anything, ever. I'd rather have a
| free, community-supported version and a premium version with
| official support. Or a basic version with free, unlimited access
| to only the most basic features, and a pro version with more
| advanced features at a cost.
|
| I just need something I can actually use without worry, and when
| my use case extends beyond the most basic of features, or the
| software becomes an important part of my daily workflow, I'll
| happily pay (and I have) for a more powerful version.
| Terretta wrote:
| > _I don 't want a free trial of anything, ever._
|
| Is this true? You don't take a new make and model of automobile
| for a test drive?
|
| Are you saying you want to pay cash for the test drive?
|
| How do you propose comparison shopping for the primary
| experience of a car which is how it feels driving it?
| bilater wrote:
| Depends on the industry I guess but in my experience customers
| trying to nickel and dime you / concerned about free trials are
| not the ones you want.
| nutrie wrote:
| Whenever I'm on the purchasing end working for a larger org, it
| is one of my initial requirements that the potential business
| partner is willing to extend their trial period, sometimes
| "indefinitely" (i. e. without an initial spec, cause I gotta talk
| to teams while getting familiar with Foo myself). I don't think
| anyone has ever refused, quite the opposite. But if they did,
| they're automatically off the table, unless they're a big deal
| such as Autodesk. They usually are not. I've done it a few times
| as an individual, with the same result. Hence I don't pay too
| much attention to whatever they say on their website.
| rhdunn wrote:
| I signed up for a trial for WoW back in the day. It was about 3
| seasons in, and the way the install worked was that you had to
| download and install each update separately, each of which was
| 2-3 GB each.
|
| I was using a slow dial-up at the time and spent the duration of
| the trial downloading the game. When I got to log in for the
| first time in a playable state, it said my trial expired! So
| ended my WoW journey.
|
| It would have made more sense to start the trial from the first
| login/entering character creation.
|
| I like the Path of Exile model. The game is free to play, and you
| pay the price of a game to unlock inventory management. -- By
| that time you know if you are invested in the game or not.
| em-bee wrote:
| similar thing with steam demo days.
|
| for a weekend or so a bunch of games are available for free to
| try them out. sounds nice until you find out that they are
| really only available for the duration of the demo days. so one
| time i looked and i found a dozen games that i wanted to try,
| but then i realized that i would have to spend the whole
| weekend playing games in order to try them all. i ended up
| trying not a single one of them because i just can't tell my
| family that i won't be available for a few days until i tested
| all those games.
|
| what would have made sense is to allow downloading all the
| games for free and then give each of them a time limit of a few
| hours to play. still not ideal (i am a slow player so i'd like
| to have a bit more time to evaluate a game) but way better than
| terminating the trial before i have even had the time to play
| anything.
| underdeserver wrote:
| Ironic. Keygens used to be how, as kids, we got around 14-day
| trials :)
| sonicanatidae wrote:
| The only ones that really bother me are crippleware.
|
| Either provide the full product, for a limited time/usage, OR,
| just skip it. The last fucking thing ANYONE needs is to work
| through the UI of an app, get everything staged, then get a
| fucking "buy me" prompt when they click "ok" to start the
| process.
|
| As far as the 7/14/30 day trials, I'm fine with those, as long as
| the above is respected, otherwise, GTFO.
| esafak wrote:
| The ideal is usage-based trials, which directly translates to
| value derived, but that's harder to implement, so you get time-
| based trials. There, I said it in one sentence.
___________________________________________________________________
(page generated 2024-05-06 23:01 UTC)