The evaluation starts long before the document arrives
By the time a request for proposal lands in your inbox, most of the decisions that matter have already been made. Someone drafted the requirements, and they drafted them by reading vendor websites. If your product shaped that list, you are competing on ground that suits you. If it did not, you are answering a document written around somebody else’s feature set.
That earlier phase is often where a chat window comes in. A researcher building a shortlist opens the chat to check a handful of specifics, gives no company name, and disappears. Handled as an ordinary support question, that conversation produces an answer and nothing else. Handled properly, it is the point at which you still have influence.
This is a different moment from the one covered in our guide to procurement and purchasing questions, where the decision has already gone your way and the conversation is about paperwork. Here, nothing has been decided at all.
How to recognise an evaluation chat
The shape is distinctive once you have seen a few. The questions are requirement-shaped rather than problem-shaped: does the product support X, is Y available, can it do Z — a checklist being worked through, not a difficulty being described. They often arrive in a burst, they are unusually precise, and they are frequently prefaced with a phrase like we are reviewing options.
The visitor is also usually anonymous by design. Public-sector and enterprise evaluations often require that vendors are treated identically, and the person doing the research may be genuinely constrained in what they can tell you. Pushing hard for a company name early tends to end the conversation.
Two things are worth noticing rather than asking about. Which pages they arrived through, and whether the questions cluster around compliance, integration or scale — the three areas that usually indicate a formal process rather than an individual buyer.
Answer what is documented, and be quick about it
Speed is a genuine advantage here, and it is one of the few advantages a small vendor has over a large one. A researcher comparing five products at four in the afternoon will record whatever they can confirm before they finish. An answer given in ninety seconds gets written into the shortlist; the same answer emailed two days later arrives after the list is closed.
So answer everything that is documented, plainly and without hedging. Yes with a link is the strongest possible response. Keeping the standard answers as canned responses means the wording stays consistent between agents, which matters more than usual when the same question may be asked of your colleague tomorrow and compared with today’s reply.
Where the honest answer is partial, say so in the same breath: that is supported in this way, and not in that way. An evaluator who catches one overstatement will discount everything else you said, and they will be reading several vendors’ answers side by side.
Never answer a requirement with a maybe
The most expensive habit in formal evaluations is optimistic language about things that do not exist. Words like planned, on the roadmap and easily configurable get transcribed into a comparison sheet as yes, and the correction surfaces during implementation, when it costs your reputation rather than the deal.
The discipline is simple and slightly uncomfortable: if the capability is not shipped and documented, the answer is no, followed by what the product does instead. Vendors who say no clearly are trusted on their yeses, and evaluators talk to each other about who was straight with them.
It also protects the person on your side of the conversation. A written chat transcript is a record; an off-hand yes in it is quotable months later, which is the same reasoning behind our list of things a chat team should never say.
Find out where you are in the process, politely
You will not always be told, but the questions are worth asking once, late in the conversation, after you have been useful. Is this for a formal evaluation, when does the decision need to be made, and is there a document you would like us to complete. Three questions, asked plainly, with no pressure attached to any of them.
The answers change what you do next. A deadline in three weeks means the security questionnaire needs to move now. A stated shortlist means the useful contribution is a clear comparison rather than a discovery call. And a plain no, we are just looking is a perfectly good answer that saves everyone a fortnight of misdirected effort.
If they will not say, do not push. Leave a documented route back — a named contact, a way to request the answers in writing — and let the transcript carry the context if they return.
Chat is the wrong container for a forty-question compliance schedule. It has no version control, no approver, and no way to attach the document the other side actually has to file. Once the conversation turns into a requirements list, the right move is to say so and offer the channel that can hold it.
That handover should carry everything already said, so nobody has to start over. Copy the transcript into the record, note which answers were given and by whom, and make sure the person completing the questionnaire can see them — because inconsistency between the chat answer and the written one is exactly what a careful evaluator is checking for.
Then keep the chat available. Evaluations run for weeks, and the quick clarification that arrives on a Tuesday afternoon is often what keeps you on the list.
How MyLiveChat fits
Transcript history is the practical piece: the researcher who asked six questions anonymously in March is findable in June when the formal document arrives, and the answers you gave then are visible rather than remembered.
Canned responses keep the frequently-asked requirement answers identical between agents, which is what stops two people giving subtly different versions of the same fact to the same evaluation.
One honest boundary: chat is not a contract channel and cannot verify who anybody is, so nothing said in a chat window should be treated as a commercial commitment by either side. Answer, record, and move the formal exchange to a channel built to hold it.
What to measure
Two numbers, both easy to get wrong if you only count chats. First, how many evaluation-shaped conversations you can identify at all — if the answer is none, agents are not recognising them, which is a training gap rather than a market signal. Tagging them consistently is what makes the count possible.
Second, what happened next. Track the share of identified evaluation chats that produced a documented follow-up, and separately the share that eventually appeared as a formal opportunity. The gap between those two is where the process is losing you, and it is usually a handover that never happened rather than an answer that was wrong.