The most common answer to anything I have written here is I already have someone.
Good. Keep them. This is not an argument that your vendor is bad at their job, and I am not going to make one — I have not seen their work, and a business that has a website with working pages, a form that delivers, and someone who answers when something breaks is ahead of a great many.
Your vendor can build any path. Whatever route you want a stranger to take from a search result to a submitted enquiry, they can build it. The constraint is not capability.
Three things do not transfer, and they are all upstream of the building.
The decision. Handed a list of changes, a competent vendor will close the tickets on the list. That is the correct behaviour and it is what you are paying for. But which path is right is not on the list, because it is not a technical question. What should the next step be for someone reading the page about your least urgent service line? Should each service line have its own route, or should they all share one? Can your intake actually take those enquiries differently, given who opens the inbox and what they do next? What do you want to have happened by the end of it? Nobody answers those from a queue, and it is not their job to. They are business questions that arrive dressed as website questions, which is why they tend to go unanswered by everyone involved.
Verification. A vendor cannot re-test their own work and produce a credible before-and-after about it. This is not about honesty. It is that the person who built the thing is the worst-placed person in the world to read whether it works, because they know where everything is, they know what the button does, and they cannot un-know it. Reading a website as a stranger is a skill that requires not having built it.
The count. Build the path with no conversion event behind it and you have the identical problem afterwards, at greater expense: no number, and now a rebuilt site nobody can evaluate. This is the one most likely to be skipped, because it is invisible on the page and nobody notices its absence at launch.
What is actually useful to hand a vendor is not a critique. It is a specification: the decided path, written down. One route per service line or one shared route. What the next step is on each page. What happens after someone submits. What the business promises about response time, in writing, so that a person can be held to it. Which enquiries are counted, where, and how you check the counting still works in six months.
That document makes a good vendor faster, because the ambiguous decisions are already made and they can go and build. It makes a bad vendor visible, for the same reason.
Some businesses will take that document to the person they already have and have them build it, and never come back. That is a designed outcome rather than a leak. The document is the product. What it is worth does not depend on who does the construction afterwards.
Which leaves one sentence, and there is no criticism anywhere in it:
Your vendor can build any path. Deciding which one, and making it countable, is a different job.
The Search-to-Consultation Diagnostic is where this gets decided for one specific business — the site read as a stranger, service line by service line, and the path written down. What it covers and what it costs is on the services page.