What software buyers ask before choosing SaaS: 100 questions, their frequency, and a reproducible coding method

Software buyers ask about ten things, in this order of urgency once a shortlist exists: what it really costs, what they are committing to, what happens to their data, how long implementation takes, whether it connects to what they already run, who answers when it breaks, where the product stops, whether it holds up at their size, whether the vendor will still exist, and how they would get out. This page enumerates all 100 questions, ten in each of those ten groups, so the list can be used and counted. It also publishes the coding method that would turn a real collection of buyer questions into frequencies. It does not publish a frequency, and the reason is stated plainly: we have not collected a buyer question dataset, so there is no denominator to divide by, and a share without a denominator is a number somebody made up.

The answer, first

The list below is a checklist, not a survey result. Its useful count is 100, built as ten groups of ten, and every question is written in the words a buyer uses rather than in the words a vendor uses.

What you can do with it today. Check your own site question by question, and see whether a buyer could find each answer without asking a salesperson. Each one your site does not answer is a page you can write. What you cannot do with it is claim that any share of buyers asks any of them. That claim needs a dataset, a denominator and a coding method, which is what the rest of this page is about.

The 100 questions, in ten groups of ten

Group one: price and total cost.

• What does it cost per user per month, in rupees, including tax.
• Is there a minimum number of users or a minimum contract value.
• What is the one time setup or onboarding fee.
• Which features are only on the higher plan.
• What does it cost to add a user mid year.
• Is there a charge for extra storage, extra records or extra API calls.
• Does the price change at renewal, and by how much.
• Is there a discount for paying annually, and how much.
• What will this cost us in total in year one, including implementation and training.
• Is there a free tier or a trial that does not need a card.

Group two: contract, commitment and renewal.

• What is the minimum contract term.
• Can we cancel mid term, and what do we forfeit.
• Does the contract renew automatically, and what notice must we give.
• Can we reduce the number of licences at renewal.
• Is there a pilot with a defined exit point.
• Who signs, and does it need a purchase order.
• Are the terms negotiable for our size of deal.
• What happens if we miss a payment.
• Is there a price lock for the term, in writing.
• Which entity are we contracting with, and under which country's law.

Group three: data, security and compliance.

• Where is our data stored, in which country.
• Do you have an India region, and can we require it.
• Which certifications do you hold, with the scope of the certificate.
• Who inside your company can see our data.
• Is data encrypted at rest and in transit, and with what.
• Do you use our data to train any model.
• How do you handle a data breach, and in what time.
• Can we sign a data processing agreement.
• How do you support our obligations under India's data protection law.
• Can you produce an audit log of who did what.

Group four: implementation and migration.

• How long does implementation take for a company our size.
• Who does the work, your team or ours.
• How do we get our existing data in, and in what format.
• What happens to records that do not map cleanly.
• Do you provide a sandbox before we go live.
• How much of our team's time will this take, in hours per week.
• What does training cost and who delivers it.
• Can we run the old system alongside for a month.
• What is the most common reason implementations run late.
• What does go live day actually look like.

Group five: integrations and fit with what we already run.

• Does it connect to our accounting software.
• Does it connect to our email and calendar.
• Is there a documented API, and is it included in our plan.
• Are there rate limits on the API, and what are they.
• Is the integration built by you or by a third party.
• Does it support single sign on, and on which plan.
• Can we export to a spreadsheet without help.
• Does it work on mobile, and is the mobile version the full product.
• Will it work with the version of the other system we are on.
• What breaks when the other system updates.

Group six: support, training and service levels.

• What are your support hours, in Indian Standard Time.
• Is support included or paid extra.
• What is your response time for a system down issue, in writing.
• Do we get a named person or a shared queue.
• Is support by chat, email or phone.
• Is there documentation we can read without logging in.
• Is there a status page showing outages and their history.
• What was your uptime last quarter.
• Do you support in any language other than English.
• What happens when our administrator leaves.

Group seven: product fit and limits.

• Does it do the one specific thing our process depends on.
• What does it not do that people expect it to do.
• Who should not buy this.
• Which of your customers look like us.
• Can we see it doing our own workflow rather than a demo script.
• How configurable is it without code.
• What needs custom development, and who pays for it.
• Is anything on the roadmap that we would be waiting for.
• How often do you ship changes, and can we opt out of one.
• What do your own users complain about most.

Group eight: scale, performance and reliability.

• How does it behave with our record volume.
• How many users can be in it at once.
• How fast is a report over a year of data.
• What are the hard limits on rows, files or attachments.
• What is your backup schedule and how long do you keep backups.
• How long would recovery take after a serious failure.
• Have you had an outage longer than a day.
• Do you have a maintenance window, and when is it.
• Does performance depend on our internet speed.
• Does it work offline at all.

Group nine: vendor viability and trust.

• How long have you been in business.
• How many customers do you have in India.
• Are you profitable or funded, and by whom.
• How large is your engineering team.
• Do you have customers in our industry.
• Can we speak to a customer who is not in your case studies.
• Where is your nearest office to us.
• What happens to us if you are acquired.
• Who are your two closest competitors, in your own words.
• Why did your last three customers who left, leave.

Group ten: exit, ownership and portability.

• If we leave, how do we get all our data out.
• In which formats, and does it include attachments and history.
• Is there a charge for an export.
• How long do you keep our data after we leave, and can we require deletion.
• Do we keep access during a notice period.
• Can we take our configuration or only our records.
• Who owns the content we create inside the product.
• Will the export load into a competitor's product without rework.
• Can you give us a deletion certificate.
• What has happened for a customer who actually left last year.

How it was measured

This is the method that turns real buyer questions into a frequency you can defend. The method is the part worth copying.

Unit of analysis. One question asked once by one buyer. Not a phrase, not a topic, never a keyword volume. If the same buyer asks about price four times in one call, that is one question in group one for that buyer, and the codebook has to say so before coding starts.

Five lawful collection sources. Use sources you own or have consent for, and say which ones you used.

• Your own enquiry inbox and web form submissions.
• Your own sales call notes, recorded with the buyer's consent.
• Your own site search log and support tickets.
• Your Search Console query report, marked separately because it is search behaviour and not conversation.
• A recruited panel of buyers who agree to paste the questions they typed into an assistant, with consent recorded.

What is not a dataset. Bought prompt data of unknown origin, scraped chat transcripts, a competitor's published chart, or anything a model produced when asked to guess what buyers ask. A list of plausible questions, which is what the 100 above are, is not evidence of frequency.

The codebook. The ten groups above, plus an eleventh code for anything that fits none of them, plus a rule for a question that spans two groups: code it to the group the buyer would put it in, and log the second group in a notes field. Publish the codebook before you publish the counts.

Two coders and an agreement measure. Two people code the same set independently. Count the questions they coded differently and publish that number. A disagreement rate you refuse to publish is a disagreement rate a reader must assume is high, and a third person resolves the disagreements.

The reporting form. Never a bare percentage. Always the count, the denominator and the collection window, in this shape: group name, then the count of questions coded to it, then the total number of questions coded, then the two dates the collection ran between, then the sources it came from. Publish the coded rows so the count can be recomputed, and state your exclusions, which should cover existing customers' support questions, students and researchers, and buyers outside your market, with a count of how many were excluded.

What the numbers were

The counts this page publishes: 100 questions, ten groups, ten questions per group. That is a count of a checklist we wrote. It is not a behavioural finding and it is labelled as such everywhere it appears.

The frequency dataset: not collected, as of 29 September 2026. We have run no buyer question study, so this page carries no category share, no "most asked question" and no ranking of the ten groups by how often they come up. The order they are printed in is our judgement of urgency, and it is labelled as judgement.

The denominators we do hold, and why they are not this. Our own audit of aiknowsus.com in September 2026 covered 24 batches and 72 conversations, in which the phrase recording that we were not cited appears 161 times in the assistant's own audits of its answers. Every count we hold, that one included, is a count of what an assistant answered. None is a count of what a buyer asked. They are different populations, and mixing them is the cheapest way to produce a false frequency, so they are kept apart.

One dated result that tells you which group matters. On 6 August 2026, in the clawlaw.in programme, the pricing page rendered its prices only after scripts had run, so what a crawler received contained no prices at all, and the prices the assistants quoted had come from an app store listing instead of from the company's own site. Claude's run recorded it, and the same day ChatGPT noticed that the site and the app store listing carried different prices for the same product and said so in its answer. Group one is not the most asked question because we counted it. It is the group where we have watched a real site lose control of its own answer.

What this cannot tell you

• It cannot tell you what your buyers ask. Your category has questions this list does not, and the only way to find them is your own inbox.
• It cannot rank the groups. Ten questions per group is a writing decision made for evenness, not a measure of importance.
• It cannot tell you what buyers type into an assistant, which is usually shorter and messier than any of the sentences above.
• It cannot be compared with anybody else's published question study unless they publish their codebook, their denominator and their disagreement rate. Almost nobody does.

Sources and change log

Sources. The 100 questions are our own, written from the buying conversations and audit work behind this product. The dated results quoted are from the clawlaw.in programme of July to September 2026 and the aiknowsus.com audit of September 2026, recorded in geo-audits/aiknowsus-com/ and in the Tier_1 baseline, gap analysis and audit response files. The 6 August 2026 pricing result can be checked from outside today.

Change log. 29 September 2026: first published with 100 questions, the coding method, and the statement that no frequency dataset exists. If we later collect one, this page will carry the counts, the denominator, the collection window, the codebook and the coder disagreement rate, and this entry will remain so the before and after can be compared.

Common questions

Why publish a question list with no frequencies at all?

Because the list is useful on its own and the frequency would be invented. A checklist you can audit your own site against changes what you write next week. A made up share changes nothing except how much a careful reader trusts the rest of the page.

Can we use this list as our FAQ page?

Not as it stands. A hundred question FAQ is a page nobody reads and nothing quotes. Answer the eight or ten your buyers actually ask, one page each, and keep the rest as an internal checklist.

Which group should we answer first?

Group one, then group three, then group ten. Price, data location, and getting out. Most companies leave all three to a sales conversation, which means no assistant and no buyer reading at nine in the evening can find them.

How many buyers would we need for a real frequency?

Enough that you are willing to print the denominator beside the count. A small coded sample with the denominator shown is more useful than a large one with the method hidden, and the honest way to publish a small sample is to call it small.

Should we ask an assistant what buyers ask, and use that?

Use it to build a checklist, as we did here, and never as evidence. In our own September 2026 audit the assistant withdrew its own claim to have searched in three separate batches. A model's account of what people ask deserves the same caution.

What to do first

Print group one, group three and group ten, which is thirty questions, and walk your own site as a buyer. Mark every one your site does not answer in public. That list is your writing plan for the next month, and it costs an hour to produce.