When the Success Criteria Change During a Dialer Pilot

Halfway through a dialer pilot, someone asks for a report that wasn't in the plan. The reps have been checking call notes and callbacks. Now the operations team wants to see callback work across several teams.

Keep the original findings, then agree what the new question means for the decision. A new requirement can be a good reason to reconsider the purchase. It shouldn't silently change what an earlier test proved, or turn an unfinished check into a pass.

Keep the original question in the notes

Suppose a team starts a fictional pilot with two reps. On Monday, the buyer and seller agree to check whether a rep can work from the intended CRM list, save a readable note on the right contact, and leave a callback that the next caller can find.

By Wednesday, a rep has shown a saved note on one contact. A callback task exists, but the colleague taking over the work hasn't checked their worklist. That is useful progress, with an original question still open.

Then operations asks for a weekly view of callbacks across teams. The question matters: that person may have to plan the work after purchase. But finding one callback and reporting on several teams are different tasks. The saved note doesn't answer the reporting question, and the new question doesn't erase the note.

Leave the Monday agreement where people can find it. Add Wednesday's request beside it, with the date and the person who needs the answer. You can change the plan without rewriting its history.

If you're still defining the initial test, start with the one-week sales dialer pilot checklist. The discussion here begins once an evaluation is under way and someone wants it to answer something different.

Ask what changed before calling it extra scope

A seller can make this conversation harder by treating every new detail as a moving goalpost. Listen for what the buyer means. The wording may be new even though the need has been there all along.

“The next caller must be able to find it” might always have meant a colleague on another team. If the seller assumed the original rep would make the callback, the pilot used an incomplete example. Correct the example and finish the original check. Don't ask the buyer to accept the narrower result because the rep can see their own task.

A different request might expose an actual failure. If everyone agreed that a callback would appear for the assigned colleague, and it doesn't, keep that result in the original findings. Calling it a new requirement would hide the very problem the pilot was meant to uncover.

Other questions really do add work. A weekly report grouped by team may involve a different screen, different permissions and a manager who hasn't used the product yet. Ask which part is necessary for the purchase and what would make the answer useful. The seller still needs to check whether the proposed product and setup can provide it.

Try: “When we wrote down the callback check, were you expecting that weekly team view as part of it? Can we look at the review you need to run?” This gives the buyer room to correct the earlier understanding.

If a new attendee introduced the request, give them enough context to explain it. The guide to bringing a stakeholder into an existing evaluation covers that conversation. You don't need to repeat the entire pitch before asking about their work.

Review the original checks and the new request together

For the fictional pilot, a short comparison could look like this:

For the new reporting request, ask the buyer to describe one review they expect to run. Which teams should appear? Does “callback this week” mean the task was created this week or is due this week? Do they need a list of outstanding work, completed attempts, or both?

Those details can change what needs to be checked. A seller shouldn't promise that a familiar-looking dashboard answers the question before inspecting its fields and filters. A buyer shouldn't have to accept a different report simply because it's easy to demonstrate.

If the answer requires separate manual work, explain that work clearly enough for the buyer to assess it. An export followed by spreadsheet editing may be acceptable for one team and unacceptable for another. A workaround is part of the proposed workflow; it needs the same practical scrutiny as the rest of the pilot.

Give the change its own decision

Ask whether the new requirement needs an answer before this buying decision. If it does, name who will check it and who will judge the result. If it doesn't, record that agreement rather than continuing to build the evaluation around it.

There may be no useful test to schedule yet. The seller might need to confirm whether the required view exists in the intended plan and setup. That check comes before asking the buyer to spend another afternoon evaluating it. “We'll show you how it works” is premature while the answer is unknown.

The buyer may also discover that the new requirement changes which product they need. If weekly team planning is essential and the proposed workflow can't support it acceptably, the sensible result can be to stop. The earlier note check still stands, but it doesn't settle the purchase.

Keep the access deadline separate. Agreeing to investigate a question doesn't extend trial access. If more time is necessary, use a specific trial-extension request and confirm the available access through the normal process. Avoid giving the buyer an investigation date that depends on access nobody has confirmed.

A change note the next person can use

Use the account notes your team already works from. A short entry needs enough context for someone who missed Wednesday's conversation:

• Original check: What result was agreed, and in which workflow?
• Current finding: What was inspected, what failed, and what remains unchecked?
• Changed question: What does the buyer need now? Is it a corrected understanding or an additional requirement?
• Decision and next work: Does this need an answer before purchase? Who will check what, and who will review it?
• Timing: Which dates are agreed, and what access or participation is still unconfirmed?

For the fictional case, the note could say:

Monday: check the intended CRM list, a readable note on the right contact, and callback handover. Jamie used the agreed list; buyer inspected one saved note Wednesday. Priya, the colleague receiving callbacks, hasn't checked her worklist, so handover remains open. Dana in operations added a weekly callback view by team Wednesday and says it is needed for the purchase decision. Nobody has demonstrated it. Morgan, the seller, will check the intended setup and explain any manual work for Dana to review. Morgan still needs to confirm when that answer will be ready. No extra buyer testing, review meeting or extended access agreed yet.

Update the note when the answer arrives. If the seller confirms a report, describe the view that was actually checked. If the buyer agrees to inspect it, add that next step. If it won't meet the need, record the gap plainly. Don't leave “checking” in the notes after the decision has changed.

Return to the work the buyer needs to do

If you're considering a dialer for your CRM or sales engagement platform, bring one example of the work you want the evaluation to settle. An original question about saving a call note and a new question about planning team callbacks can both be reasonable. Write each one clearly enough that the person reviewing the pilot can see which answer they have.