Salesforce's FDE Slackbot Says Leave the Call With Better Questions. Leave It With Rows.

Salesforce's Ask Slackbot column answered a forward deployed engineer this week, and it ends on a line I want to replace. This is an Agent Drop: three artifacts an FDE can carry into the next kickoff, and the column's own prompt pointed at the right one.

The short version

Salesforce's November 5 Ask Slackbot column, answered by the Slackbot of a Salesforce forward deployed engineer from that person's own threads, tells an FDE facing a customer with firm opinions to treat the first answer as a draft, swap "why" for "what happens next," bring evidence instead of opinions, say what they do not know, and leave the call with fewer answers than they wanted and better questions than they brought. The advice is good and the close is where the gap gets found at go-live. A firm opinion is a compressed story about a pain, as the column says; the uncompressed version is a record where the pain happened. Every "what happens next" gets a second half, show me one, and three records per opinion, labeled right or wrong by the customer's expert on the call, are the first rows of the eval. Run the product as it stands against them before the second call, and the evidence sentence becomes a number about the customer's own cases, which is how Colin Jarvis's team could say 60 percent at scoping. The column's divergence prompt, read the last five engagement threads for where the first ask and the final build diverged, is the right prompt on the wrong artifact: five threads is a sample, and my discovery-week ranker buried a three-call theme under a 31-call one when the three were the renewal. The handshake page, every promised outcome in a column, ships, builds, or no, already records what moved and when, so run the prompt there. The drop is the page, the second half of every question, and the first rows with the number.

What the column says

The column is a monthly format. A reader writes in, and the Slackbot of a Salesforce employee in that role answers from the employee's real Slack conversations, customer implementations, and documents, with names removed and the patterns generalized, as the piece describes its own method. This month the role is forward deployed engineer, and the question is the one every FDE gets: a new customer with firm opinions about what they want built, an engineer who is supposed to be both the expert and the listener, and two failure modes, accepting the first answer or interrogating the customer.

The answer has four moves. Treat the first answer as a draft, not a verdict; customers with firm opinions have lived with the problem longer than you have, so ask what happened that makes their approach seem obvious, and the Slackbot notes an engagement where the original approach was replaced mid-build. Swap "why do you want that feature," which sounds like a challenge, for "what does that feature unlock for your team," which sounds like interest and gets the same information. Bring evidence, not opinions: in one exchange the FDE described the customer's existing setup, hundreds of mapping records and dozens of categories, in concrete numbers before proposing anything, and numbers let the customer reach the conclusion themselves. Say what you do not know, out loud, the way the FDE opened write-ups with what they were confident about and what they would want to validate first.

Then the close: leave the call with fewer answers than you wanted and better questions than you brought. You can build the rest later.

And a stealable prompt for the FDE: look at the last five customer engagement threads and kickoff notes, for each say what the customer first asked for, what the project ended up needing, and the moment the difference first showed up, then draft five open-ended discovery questions that would have surfaced that gap earlier.

Where I get off

The four moves are right. The close is where the deployment gets found out at go-live.

What surfaces the gap earlier is not a better question. It is a row. The FDE Writes the Eval: Almost Right Has a Number has the rule: the eval is the deployment artifact, not the demo or the deck. One versioned set of the customer's real cases with agreed-correct answers, a target against the human baseline, and a pass rule a machine can check, written by the FDE before the build, with the customer's experts supplying the labels. The number exists before the work does. That is how Colin Jarvis's team, in the sequence reported there, knew the telecom voice model was at 60 percent at scoping, and could say so to the customer instead of finding out at go-live.

The column already has the raw material. A firm opinion is a compressed story about a pain point, in its own words. The uncompressed version is a record where the pain happened: a claim, a ticket, a mapping that went wrong, a call that escalated. So every "what happens next" question gets a second half.

Show me one.

Three records per firm opinion. On the call, the customer's own expert says what the right answer was for each. That is the first rows of the eval, and the customer labeled them, which is the part that is hard to get later. Then, before the second call, run the product as it stands against those rows. The column's best sentence, "here's what I'm seeing in the numbers," now has a number in it about the customer's own cases, not about their configuration.

The difference between the two kinds of evidence is the difference between describing the customer's setup and describing what the product does with it. Hundreds of mapping records is a fact about them. The share of their labeled rows the product gets right is a fact about the engagement.

The prompt is right. Point it at the page.

The divergence prompt is the best thing in the column, and I would run it. Where the first ask and the final build diverged, and the moment it first showed up, is exactly the question product needs answered about every deployment.

Five Slack threads is a sample, though, and samples get ranked. In The Three-Call Theme Was the Renewal. Count What Landed, Not Fixes I wrote up what my opportunity ranker did in the agent discovery week: it scored on frequency, so a theme in 31 calls beat a theme in 3 calls, and the 3 were our largest enterprise account describing an integration regression that put the renewal at risk. A prompt that reads five threads and finds the common pattern will find the common pattern. The divergence that costs the most is usually in one thread.

Divergence has an address already. In the Room, Not on the Quota: Who Owns the FDE Promise is the one-page handshake attached to the contract: every outcome in the proposal, sorted by the FDE into three columns. Ships, with a date. Builds, with an estimate and the engineer who has to say yes. No, written before the signature rather than discovered after it. Sales owns the number, the FDE owns the columns, both names on the page.

Run the prompt there. Which outcomes moved from ships to builds, which moved from builds to no, and the date each one moved. That is the moment the difference first showed up, with the column it started in, and it is a log rather than a memory. The five discovery questions the prompt drafts at the end come out sharper, because they come from what was promised instead of what was discussed.

The drop

Three things to ship before the next kickoff, in the order they get used.

The handshake page, pre-filled from the proposal. Every outcome, three columns, dates where the column has them. Half an afternoon, and the call now has a thing to be measured against.

The second half of every question. Beside each "what does that unlock," write "show me one." Three records per firm opinion, labeled by the customer's expert on the call. Those are the first rows, and they are the customer's.

The first rows run against the product as it stands. The number goes into the second call. If it is 60 percent, say 60 percent, the way Jarvis's team did. The column's last move, say what you do not know out loud, is easiest when the thing you do not know has a number next to it.

This is the AI Product Management thesis at the kickoff: the part of the job that collapsed is the question-asking, and the part nobody trained for is deciding what the first rows are. The FDE Transition has the rest of the series.

This week, if you have a kickoff on the calendar: take the proposal, sort it into the three columns, and for the customer's firmest opinion write the one sentence that asks for a record. Bring both to the call.

Related answer: What should a forward deployed engineer leave a discovery call with?

Sources: Salesforce Newsroom, "Ask (a Forward Deployed Engineer's) Slackbot," November 5, 2026, read in full; the column is answered by the Slackbot of an unnamed Salesforce forward deployed engineer, grounded in that person's threads and documents as the piece describes its method, and every move, example, and prompt is as published. Falk Gottlob, "The FDE Writes the Eval: Almost Right Has a Number," where Colin Jarvis's sequence and the 60 percent at scoping are as reported there; "In the Room, Not on the Quota: Who Owns the FDE Promise" (the handshake page); and "The Three-Call Theme Was the Renewal. Count What Landed, Not Fixes" (the 31 against 3).