Can you explain what will change in my business?
This is where I would begin the conversation. Ask the consultant to describe the current process and the proposed change in everyday language. They should identify the trigger, the work performed, and the person who receives the result. If you hear only a list of tools, ask again for the business action those tools will support.
Use a redacted example from your work. A Valencia service office might bring an incomplete appointment request and explain how staff currently resolve it. Ask which steps the proposed assistant handles and which remain with employees. You are not asking for a finished build during an interview. You are checking whether the consultant understands the task well enough to scope it. An unanswered business question should become a discovery item, not an unsupported assumption.
What will you need from my staff and my accounts?
Ask for the information, access, and decisions required to begin. Who explains the workflow? Who provides the approved source material? Who can authorize a change? I would want those dependencies listed so the project does not stall while everyone waits for someone else to act. Your staff's participation is part of the work.
Then ask why each requested permission is necessary. A consultant preparing internal drafts may not need authority to send customer messages. Find out where data will go, who can view it, and how access will be removed. Do not send passwords in a proposal conversation. Ask the provider to describe the proper access process for the systems involved. If the answer is simply to grant full control everywhere, press for a narrower explanation.
How will you prove that this works outside a demo?
Ask the consultant to describe acceptance tests before building. A useful answer includes ordinary inputs, incomplete requests, unexpected wording, and unavailable connections. I would ask to see the resulting record as well as the AI response. A correct-looking response does not prove that the intended action happened in the right place.
Ask how errors are reported and who reviews them. Can your employee reject a result? Can the process be paused without losing new requests? What happens if an action is retried? These questions expose the difference between generating text and running a business workflow. Have the provider explain a failed test they would expect to catch in your proposed setup. They do not need to disclose another client's details to show how they reason about failure.
What exactly am I buying and what stays mine?
Request a written scope that identifies deliverables and exclusions. Ask whether the work includes documentation, staff training, ongoing checks, and future changes. If support is offered, find out what it covers and how to request it. I would separate fixing an agreed function from adding a new function so neither side has to guess later.
Ask who owns the accounts and how you obtain the configuration or custom work when the engagement ends. Have the consultant identify any outside services the workflow depends on. You should understand recurring obligations even when a proposal focuses on the initial build. This is also the place to clarify acceptance and transition terms. A verbal explanation can help you understand the proposal, but the agreement should reflect the arrangement you intend to approve.
What answer would make me slow down before hiring?
I would slow down if a provider claims there is no meaningful failure risk, refuses to explain data access, or cannot name who will build the project. Broad promises of business improvement also need a defined mechanism and a way to check results. Ask what evidence would lead the consultant to recommend stopping or changing the approach.
A useful consultant should be able to say that a task does not need AI. They should also be able to identify a missing fact without filling it in for you. I want you to leave the conversation knowing what happens next, what you must supply, and how you will judge the work. You can bring these questions to me. A concrete discussion about a real task is a better starting point than choosing software from a presentation.
Which hiring questions deserve a direct answer?
Should I ask for a demonstration before hiring?
I would ask for a relevant example and an explanation of its limits. The provider can use fictional data. You want to understand their method without asking them to expose private client information.
How do I ask about mistakes without sounding difficult?
Ask what happens when a required field is missing or a connection fails. Those are normal operating questions. I expect a builder to explain detection, recovery, and human responsibility.
What if I do not understand the technical answer?
Ask the consultant to show the input, action, and result on a simple diagram. I would keep asking until the explanation is clear enough for you to approve or reject the proposed behavior.
Should support be part of the initial discussion?
Yes. I would clarify support coverage, reporting routes, maintenance ownership, and the manual fallback before construction begins. Do not wait for a failure to discover that support was never included.
What should the written proposal make clear?
I want the task boundary, deliverables, required access, acceptance process, ownership, exclusions, and support responsibilities stated plainly. The proposal should let your team identify what completion actually means.