When a Buyer Sends a Vendor Questionnaire During a Sales Trial

A buyer sends a spreadsheet halfway through a trial. Some rows ask about the calling workflow you've already shown. Others ask about permissions, reporting or arrangements that nobody has discussed. The buyer wants it back before the next review.

Start by finding out what the questionnaire is meant to decide. Then answer for the setup the buyer is actually evaluating. A partly supported workflow needs an explanation; an unanswered question needs an owner and a next step. Filling every cell with “yes” won't help the buyer choose if the answer changes when someone tries the workflow.

Ask how the buyer will use the answers

A questionnaire might determine whether a trial can continue, whether a manager accepts its results or whether the vendor can enter the buyer's purchasing process. Ask your contact which of those decisions is coming up and who will read the response.

That changes what you need to prepare. A sales manager checking how call notes reach a contact record needs a clear workflow answer. An administrator comparing permissions needs the proposed roles and workspace. Security and contract questions belong with the people responsible for those subjects. The rep can coordinate the response without answering on their behalf.

Ask which rows matter for the upcoming decision. That isn't a request to skip the rest. It helps you distinguish a question that could stop the pilot from one the buyer expects to finish later. If every row is required before another call can be made, record that requirement and discuss the schedule openly.

Also confirm how the buyer wants changes returned. If their form has fixed row numbers, keep them. If it only accepts yes or no, ask where a qualified answer or unresolved item should go. Don't make the buyer compare a renamed spreadsheet with an attachment full of answers they cannot match to it.

Read each question against the proposed setup

A broad question often hides a specific requirement. “Does the system sync with our CRM?” could mean saving a call note, completing a task, updating an opportunity or making a recording available to a manager. One of those working doesn't settle the others.

Write the requirement beside the row before choosing an answer. Include the platform, starting view, user role and action when those details affect the result. You don't need to repeat the whole trial plan. You do need enough context for the next person to understand what was checked.

Sometimes you can answer immediately from a current approved document that covers the exact setup. Other rows need a demonstration or a product colleague's review. Keep the source beside the answer, including when it was checked. An old response from another deal can point you toward the right person, but it isn't evidence that the same answer applies now.

If the buyer hasn't chosen the configuration, say what information you need. For example: “Which task view will the pilot reps use? We can check task completion there once that is confirmed.” That's a useful response to an open question. A confident answer about a different view is not.

Work through one awkward row

Consider this fictional vendor evaluation. It illustrates how to write a response, rather than describing a Trellus feature.

The questionnaire asks: “Does saving the call log automatically complete the CRM task?” In the proposed trial, the rep has shown a note being saved to the contact. Nobody has yet checked automatic task completion in the buyer's chosen task view.

A bare “yes” would let the buyer assume both actions have been demonstrated. A bare “no” would also go beyond what the team knows. The response needs to separate the observed action from the open one:

The demonstrated workflow saves the call note to the contact. Automatic completion of the CRM task has not been checked in the proposed task view. We will confirm that behavior with the administrator before the pilot's task-completion review. If a separate task-completion step is acceptable, we can include it in the trial plan while we check.

Ask the buyer to decide whether that separate step would be acceptable. Keep their answer beside the row so the trial plan reflects what they actually agreed to.

Suppose the administrator checks the view and finds that task completion is manual. Update the same row with the finding and ask whether the separate step meets the requirement. If automatic completion is mandatory, the row remains unmet. Clear wording makes that buying decision possible without another round of interpretation.

If the check instead confirms automatic completion, describe the configuration that was checked. Keep any relevant prerequisite beside the answer. “Confirmed in the pilot's assigned task view” is more useful than a claim about every possible CRM setup.

Give open rows a person and a useful next step

“Checking internally” gets old quickly. For each unresolved row, identify who can answer it and what they need to inspect. Give the buyer a date for the next update that the owner has actually agreed to. That can be an update date even when the final answer will take longer.

Keep three situations distinct:

• An answer is confirmed for the proposed setup. Return it with its relevant qualification and source.
• The question needs clarification. Tell the buyer exactly which detail is missing and why it changes the answer.
• The answer is still being checked. Name the check and when you'll report back. Leave the product answer open.

A completed internal investigation can produce an unwelcome answer. Return it clearly. If the requirement isn't met, identify the practical consequence and discuss whether a different approach is useful. A planned improvement doesn't satisfy a requirement for a capability the buyer needs today.

For rollout questions, carry the unresolved dependency into the implementation plan. A questionnaire answer and a provisional start date shouldn't tell two different stories about what's ready.

Use a small response worksheet

Download the blank response worksheet to copy into your working register.

Keep one working register even if several colleagues contribute answers. Copy these fields for each row that needs attention:

Buyer row number and exact question:
What the buyer needs to decide:
Proposed platform, view and user role:
Current response and relevant qualification:
Source or check, with date:
What remains unknown or unmet:
Person responsible for the next check:
Agreed next update date and recipient:

The register is for coordinating the work. Return the buyer's requested format as well, rather than asking them to adopt your spreadsheet. Before sending, read each answer beside its original question. Check that a qualification didn't disappear when someone shortened the text to fit a cell.

Ask a second reader to look for broad words such as “all,” “automatic” and “included.” Those words may be accurate, but they deserve a closer check. Does the answer cover the proposed users and configuration? Does it describe a released capability or a request somebody agreed to investigate? Does an attached document actually support the statement beside it?

Keep later corrections attached to the question

After returning the form, a colleague may find that an answer needs changing. Correct the original row, identify the previous wording and explain what the change means for the trial. Send it to the people who received the earlier response. The guide to correcting information already sent to a buyer includes a worked reply for that situation.

If the questionnaire is still open when you hand the deal to another rep, include the row numbers, latest answers and next promised update. The buyer should be able to continue the review without explaining the same uncertainty again.

The useful finish is a form the buyer can act on: checked answers for the proposed setup, visible open requirements and a clear way to resolve them. Take one unresolved row to the next trial review and agree on the check that will settle it.