What information does a consultancy need to quote an AI implementation?

# Why isn’t “we want to use AI” enough to get a quote?

The same phrase can describe very different projects:

• set up a Claude or ChatGPT enterprise workspace for twenty people;
• train a team to work with documents;
• create an assistant that consults internal policies;
• analyzing calls and recording results in a CRM;
• extract data from case files and send it to an ERP;
• build a predictive model using historical data;
• automate part of a process with human approval.

Each case changes the architecture, permissions, effort, risks, and support. A license can be activated in days; an integration with legacy systems may require technical access, testing, security, and coordination with several vendors.

That’s why a serious quote doesn’t start with “how many users are there?” It starts with “what decision or task needs to improve, and how is it done today?”

# The nine pieces of information that define the scope

# 1. Expected result

A useful statement describes an observable change. For example: “reduce the time needed to prepare a call summary and improve capture of the next step, without updating sensitive fields without confirmation.”

There’s no need to promise a percentage before measuring. But it is necessary to identify the user, the task, how often it occurs, and the decision you want to improve.

# 2. Current process

The actual process rarely matches a diagram completely. It’s helpful to observe one or two cases from start to finish and record inputs, owners, tools, wait times, rework, and exceptions.

Useful questions:

• What triggers the process?
• Who receives the request?
• What information do they consult?
• What do they decide, and with what authority?
• What does it produce in the end?
• Where is it recorded?
• What happens when information is missing?
• Which cases fall outside the normal workflow?

Without this review, a proposal may automate a visible step while leaving the actual bottleneck untouched.

# 3. Volume and frequency

The consultancy needs verifiable ranges: calls per week, documents per month, average page count, simultaneous users, languages, hours, and projected growth.

Volume affects API usage, storage, queues, performance, and support. It may also show that the problem doesn’t require development: if there are few cases and a high degree of human judgment, an existing platform with a clear procedure may be sufficient.

# 4. Available data

It’s not enough to know that “there’s a database.” You need to review its format, quality, coverage, age, duplicates, empty fields, permissions, and meaning.

A pilot usually requires representative, authorized examples. A sample should include easy, difficult, incomplete, and exceptional cases. If only the best files are shown, the estimate will be too optimistic.

Personal, confidential, financial, legal, clinical, or strategic information must also be identified. That classification affects the product, contract, infrastructure, retention, and access.

# 5. Systems and integrations

The difference between “using AI” and “integrating AI” is usually here. You need to list the CRM, ERP, telephony, document storage, email, authentication, and any system of record.

For each system, it’s helpful to know:

• who administers it;
• whether it has an API and up-to-date documentation;
• what permissions can be granted;
• whether a test environment is available;
• what limits or costs apply;
• what data needs to be read or written;
• how to reverse an incorrect action.

An integration without confirmed access remains a hypothesis, not a defined scope.

# 6. Users, roles, and adoption

Not everyone needs the same level of access. Identify end users, supervisors, administrators, security, legal, IT, and the process owner. Define who can consult sources, approve an output, modify instructions, connect data, and review logs.

Adoption also has a cost. It includes use case design, training, materials, initial support, and follow-up. Buying seats without preparing the work can lead to a lot of activity and little operational change.

# 7. Risk and compliance

The most useful question is: What happens if the output is incorrect, incomplete, late, or visible to someone who should not see it?

The answer determines whether a light review is enough or whether validations, dual approval, auditing, data isolation, and specialized advice are needed. The bar should be higher in medicine, law, finance, human resources, security, or infrastructure.

The provider needs to know the applicable policies and obligations, but must not invent them. The organization remains responsible for approving legal, privacy, and industry requirements.

# 8. Level of autonomy

There is a big difference between:

1. searching for information;
2. drafting a proposal;
3. recommending an action;
4. preparing a change for approval;
5. executing automatically.

Each level adds controls. A quote should specify which actions are in scope, which require review, and which are prohibited. “AI agent” is not a sufficient specification.

# 9. Metrics and acceptance

Before building, the parties should agree on how they will determine whether the pilot worked.

Metrics may include time per case, extraction accuracy, corrections, coverage, adoption, cost per transaction, and satisfaction. Evaluating quality requires a set of cases and a human reference.

The acceptance criteria should include limits. A system may save time and still not be suitable for certain documents or decisions.

# What documents speed up a quote?

You do not need to prepare a perfect file. These items are usually enough for an initial estimate:

• a one-page description of the objective;
• a simple diagram of the current process;
• a list of systems and people responsible;
• approximate volumes, with source and period;
• anonymized samples or controlled access;
• user roles and number of people;
• relevant security and privacy policies;
• date, budget, or procurement constraints;
• success criteria and the person who will approve the pilot.

If some items are unavailable, the assessment can produce them. The important thing is to distinguish what has been verified, what has been estimated, and what is still pending.

# What should the proposal break out separately?

A clear proposal distinguishes between costs of different types.

# Licenses and usage

This includes platform seats, API usage, storage, or other third-party services. Prices and terms can change, so they should be dated and specify who contracts with and pays the provider.

# Assessment and design

This includes interviews, observation, data inventory, risk assessment, use case definition, architecture, and pilot planning. It is professional work, even when there is no code yet.

# Configuration and implementation

This may include workspaces, permissions, instructions, templates, connectors, development, testing, monitoring, and documentation.

# Training and adoption

It should specify the audience, duration, materials, practice with real cases, support, and measurement. A generic session does not replace preparation of the process.

# Operations and improvement

This includes support, quality reviews, changes, variable costs, periodic evaluation, and incident response. It should also clarify what counts as maintenance and what constitutes a new scope of work.

# When is a paid assessment phase worthwhile?

It is worthwhile when several departments are interested, no process has been defined, the data have not been reviewed, integration depends on third parties, or the risk of a poor decision is significant.

The phase should have a defined duration and concrete deliverables. For example:

• process map and people responsible;
• data and systems inventory;
• prioritization of use cases;
• initial risks and controls;
• platform, API, or hybrid approach alternatives;
• scope and pilot metrics;
• investment range for the next phase;
• recommendation to proceed, prepare the data, or stop.

An assessment should not be open-ended consulting. Its outcome is to reduce uncertainty enough to make a decision.

# Why can some quotes only offer a range?

A range is responsible when the main variables have been identified but not yet verified. It should include assumptions and factors that could change it.

Example: the estimate assumes a documented API, one language, two document types, and human review before writing to the CRM. If ten formats, a system without an API, or the need to operate in real time later come up, the scope changes.

The problem isn’t the range. The problem is hiding uncertainty behind an exact figure.

# Warning signs in an AI quote

Review the proposal carefully if it:

• starts with the tool rather than the process;
• promises savings or sales without a baseline;
• combines licenses with implementation;
• doesn’t identify recurring costs;
• assumes access to unverified systems;
• doesn’t explain data handling;
• doesn’t include evaluation using real cases;
• doesn’t define human review or rollback;
• calls a full development project a “pilot”;
• doesn’t specify who approves the result.

A good proposal may include conditions and open questions. That is more honest than pretending to be certain.

# Brief template for requesting a quote

You can start with this format:

Objective: what task or decision you want to improve. Users: who will participate and how many people. Current process: steps, tools, and exceptions. Volume: cases per period, size, and hours of operation. Data: sources, formats, sensitivity, and known quality. Systems: required integrations and technical owners. Autonomy: what the AI can propose, approve, or execute. Risks: consequences of an incorrect output. Success: metrics and the person who will sign off on the pilot. Constraints: timeline, budget, procurement, and policies.

You don’t need to answer everything to request a conversation. It does help identify from the outset what needs to be investigated.

# Frequently asked questions

# Can you provide a quote without reviewing the data?

We can provide a conditional range or quote an assessment. A fixed price for implementation without reviewing examples, permissions, and data quality usually depends on assumptions that should be made explicit.

# Does a Claude or ChatGPT license include implementation?

No. A license provides access to the product and its features according to the plan. Use case design, configuration, integration, policies, training, evaluation, and support are separate activities.

# Who should attend the first meeting?

The process owner and someone who knows the operations. If integration or sensitive data is involved, IT, security, privacy, or legal should also participate, as appropriate. You don’t need to bring the whole organization together to define the initial hypothesis.

# How long does an assessment take?

It depends on the number of processes, systems, and stakeholders involved. It should have a concise scope and defined deliverables. Its duration should not be presented as universal before the context is known.

# Does the consultancy have to resell the licenses?

Not necessarily. The company can contract directly with the provider and separately hire for assessment, configuration, integration, governance, and adoption. This also clarifies the relationship and avoids implying commercial authorizations that do not exist.

# Conclusion

An AI quote should not price an abstract idea. It should price a defined change to a process, with data, systems, people, controls, and a way to verify results.

When key details are missing, the next step is not to inflate the scope or promise a number. It is to reduce uncertainty with a brief assessment.

Commercial discussions improve when both parties separate licensing, implementation, training, and operations. This lets the company compare options and know exactly what it is buying.

# Sources and references

• NIST AI RMF Core: govern, map, measure, and manage
• NIST AI Risk Management Framework: Generative AI Profile
• OpenAI enterprise privacy
• Data retention for Anthropic commercial products