What buyers ask AI before choosing a data analytics consultancy

Buyers ask how to get one reliable number out of systems that disagree, what a dashboard or warehouse project costs and takes, and whether to hire an analyst instead of engaging a consultancy. Tool comparisons come next, and for many buyers that is how they arrive.

The questions, in the words buyers use

The real problem, in business words

• "Our sales report and our accounts do not match, how do we reconcile them"
• "We make our monthly MIS by hand in Excel, how do we stop"
• "We cannot trust our stock numbers across branches"
• "Every department has its own version of revenue"

Cost and time

• "Cost of a Power BI or Tableau implementation"
• "How long to build a data warehouse for a company of our size"
• "What does a single dashboard cost to build"
• "Ongoing cost after the project is done"

Build, buy or hire

• "Hire a data analyst or engage a consultancy"
• "Can our existing IT team do this"
• "Should we just use the reporting inside our ERP"
• "Do we need a warehouse at all, or is a spreadsheet enough for now"

Tools, risk and handover

• "Power BI versus Tableau versus Looker Studio"
• "Snowflake versus Databricks versus BigQuery"
• "Who sees what, how do we control access"
• "What happens when the consultant leaves, can we maintain it"
• "Where will our data be stored and is that allowed"

What a good answer looks like

Write the problem pages in the buyer's words, not yours. A page titled after the mismatch between two systems will be read by the person who has that mismatch. A page titled modern data platform enablement will not be read by anybody.

On cost, give a scoped starter engagement with a price and a duration, and explain what makes a project bigger: number of source systems, data quality, how many people need access, how far back history has to be rebuilt.

On build, buy or hire, answer honestly, including the cases where a buyer should not hire you. Small companies often genuinely need a tidy spreadsheet and one free tool, and saying so is the most persuasive thing on your site.

On handover, publish what you leave behind: documentation, naming conventions, who can run it, what training is included. This is the buyer's real fear and nobody addresses it.

Where you are probably missing

• Pages about capabilities instead of problems, so no page matches a question.
• No pricing at all, not even a scoped first step.
• No tool comparison pages, although the comparison is the query.
• No handover or maintenance page.
• Nothing about the Indian systems buyers actually run, such as Tally or a local ERP.
• No honest answer to the small company case, which costs you credibility with everyone else.

What to publish first

• Four problem pages, titled the way the problem is described in a management meeting.
• A scoped starter engagement with a price, a duration and a deliverable.
• One page per source system you connect, starting with the most common one in your market.
• A handover page listing exactly what the client keeps.
• One honest comparison page on the tools you implement, including where the cheaper option is fine.

That is a fortnight of writing and it moves you from a category where nobody can verify anything into one where a buyer can check you against a partner listing and a stated price.

A worked example of a handover page

The buyer's real fear is being left with something nobody in the company can maintain. Here is the page that answers it.

List what the client receives, by name. The source code and the transformation logic in their own repository, not yours. A written data dictionary listing every field in the reporting layer, what it means and where it comes from. The mapping tables, held in a form the finance team can edit. A diagram of the flow from each source system to each dashboard. Access credentials and account ownership transferred into the client's own accounts, with your access removed on a stated date. A run book: what runs when, what to check each morning, what the common failures look like and how to restart them. A record of every decision where two definitions were possible and one was chosen, with who chose it.

Then say who can run it afterwards, honestly: what skill level is required, how many hours a week it typically takes, and what you recommend if the client has nobody in that role. Offer a support arrangement, priced, and make clear the client is not obliged to take it.

A consultancy that publishes that page is telling a buyer they are not being trapped, which is the single largest objection in the category.

What these questions do not include

They do not include your methodology diagram or the name you have given your delivery framework. Buyers do not search for those and cannot compare them.

They also do not include the answer to which tool is best in general. It depends on the client's size, budget, existing licences and the skills of whoever will maintain it, and an honest page says so while still giving a recommendation for stated situations.

And they do not include anything that assumes the data is clean. Many of these projects turn out to be a data quality project wearing a dashboard project's clothes, and it is better to say that before the contract than after.

Common questions

Which page in the list is worth writing first?

The problem page that matches your most common enquiry, written in the words a management meeting uses. It is the page a buyer recognises themselves in, and recognition is what produces the enquiry.

Should we tell small companies they do not need us?

Yes, and say what they should do instead: tidy the source data, agree one definition, and use the reporting already inside their existing systems. Some of them will grow into clients, and all of them will believe the rest of your site.

How do we answer the build or hire question?

By describing both honestly. A permanent analyst is better for continuous work, knows the business and costs a salary. A consultancy is better for building something once, brings people who have done it before, and leaves. Say which parts of your own work would be better done in house, because there always are some.

Buyers ask what it costs to run afterwards. What do we say?

Give the components: platform and licence costs, storage and compute, and the human time to maintain and extend it. Buyers are routinely surprised by the running cost, and the consultancy that warned them is the one they keep.

Do we need to write about data protection?

Yes, one page. Where data sits, who can see it, how long you keep copies, what happens at the end of the engagement, and how you handle personal data under the Digital Personal Data Protection Act 2023. This question increasingly arrives from a legal team rather than from IT.

What to do first

Write the handover page this week. It is short, it is entirely factual, and it removes the objection that quietly ends most of these conversations.