Buying quantum consultancy: how to scope an industrial pilot

An industrial quantum consultancy pilot should purchase a defined body of work and a reviewable result. Specify the business problem, representative data, classical reference, computing allowance, deliverables and stopping criteria before choosing the supplier. Free introductory advice, professional services and collaborative research serve different purposes and need different expectations. The aim may be feasibility or capability building rather than a production advantage. Current purchasing routes and the proposed scoping framework below were reviewed on 29 September 2026.

Which kinds of service can a company buy?

The Braket expert-advice documentation distinguishes free half-hour office hours from professional services and collaborative research. It identifies IonQ, QuEra and Rigetti services available through AWS Marketplace, as well as Amazon Advanced Solutions Lab engagements. An introductory conversation can help locate the problem, but it is not a promise to deliver a prototype. Obtain an explicit scope and quotation for the work the organisation actually needs.

There are also routes tied to a particular computing environment. D-Wave Launch describes stages from problem discovery and proof of concept through production pilot and implementation, with expertise and Leap access forming part of its proposition. These are examples of purchasing channels, not an exhaustive consultancy directory. Their published descriptions establish what the providers offer to discuss; the statement of work determines what a particular customer will receive.

What problem should the brief ask the consultant to solve?

Describe the business decision before selecting an algorithm or processor. An industrial scheduling project, for example, needs to specify the production constraints, current planning process and value of a better feasible schedule. The brief should identify which part of that problem is in scope and which operational systems remain outside the pilot. It should also explain the decision that management will make after receiving the results, such as continuing research, funding integration or stopping the work.

Avoid making the conclusion part of the assignment. A consultant asked to demonstrate quantum advantage may have too little freedom to recommend a simpler route or report a negative result. A better commission asks for a reproducible assessment against agreed alternatives. Amazon Advanced Solutions Lab explicitly describes developing quantum prototypes alongside classical solutions and benchmarking applications. That provides a concrete example of a research engagement whose deliverable is knowledge about the problem, not a guaranteed business outcome.

What data and baseline are needed before execution?

Give the project a data owner and an agreed representative dataset. Explain missing fields, known biases, access restrictions and the difference between a convenient sample and the operational problem. If synthetic data is used, document which properties it preserves and which conclusions it cannot support. Delays in data clearance should change the delivery plan explicitly rather than quietly compressing the time available for analysis and validation.

The classical baseline should be credible enough that a result can inform a purchasing decision. Establish who implements it, what tuning effort it receives and how its output will be assessed. For optimisation, feasibility and solution quality need to be considered together. For simulation, define the reference accuracy and what is known about the answer. These are suggested scoping requirements, not claims that every method can be tested conclusively in a small pilot. Where uncertainty remains, the report should explain what further evidence would resolve it.

How should computing access and supplier responsibilities be bounded?

Specify whether processor access, simulation, classical cloud resources and support are included in the consultancy fee or charged separately. Name the account owner and the person authorised to increase the allowance. Request enough execution records to connect spending with delivered experiments. A budget for consultancy days does not automatically control cloud consumption, while an access credit does not cover all the work needed to formulate and interpret a problem.

Clarify whether the consultant is independent of the hardware channel or also resells access and supplies the implementation. Either arrangement can be workable, but the customer should understand the commercial relationship. The cloud-pricing guide explains why tasks, shots and time allocations need different controls. If the chosen device becomes unavailable or changes during the project, the contract should state how the team decides whether to substitute a target, revise the experiment or stop.

What deliverables and rights make the work reusable?

A useful handover includes the problem formulation, executable code where agreed, environment information, data-handling record, baseline results and interpretation of limitations. The customer needs enough material to understand and, where rights permit, repeat the experiment. A slide presentation alone may be appropriate for a strategy workshop, but it is rarely sufficient for a technical feasibility commission. Specify the intended audience for each deliverable so research detail and management conclusions are both usable.

Agree ownership and licences before novel work begins. Distinguish the supplier's pre-existing tools, customer data, newly developed code and any jointly created research. Address publication review, patent discussions and the right to continue development with another provider. These terms depend on the engagement; a public description of collaborative research does not disclose the customer's eventual IP rights. Include practical knowledge transfer, such as a working session in which the internal team reruns and explains an agreed example.

Who should judge milestones and decide whether to continue?

Retain internal domain expertise throughout the engagement. IBM's guidance on assembling quantum teams distinguishes application expertise, technical leadership and business sponsorship. A consultancy does not remove those customer responsibilities. The domain owner should judge whether the formulation preserves the real business constraints, while a technical reviewer assesses the evidence and a sponsor decides whether the next stage is proportionate to its likely value.

Tie payments and continuation decisions to observable deliverables. An initial milestone might accept the data and baseline; a later one may accept a reproducible experiment and its report. Stopping can be the correct outcome when the formulation is unsuitable, the reference already meets the need or the available resources cannot resolve the question. For investors examining consultancy revenue, distinguish paid expertise from recurring software or processor demand. A successful engagement demonstrates delivery of the agreed work; repeat business depends on what the customer needs next and why it chooses to pay again.