Turn a Vague Request Into a Decision

GTM Lab's VP of Marketing sends four words to the team channel: “Can we use AI to qualify our inbound?”

Three people read it and hear three different things. The marketing operations manager hears a spam filter, because she is the one who deletes the staffing agencies every morning. The sales manager hears a routing rule, because his complaint is that good requests sit for two days. The person who will actually build it hears a scoring model, because that is the shape of the last three things he was asked for. All three start work. None of them is wrong about the words.

A request names a topic. A decision names an answer.

“Qualify our inbound” is a subject heading. You cannot implement a subject heading, but you can implement your own private interpretation of one, which is what happens.

A decision, written properly, has four parts, and the test for whether you have them is blunt: could two people implement this separately, without talking, and produce the same behavior?

A trigger is the observable event that fires the decision. Not a schedule, not a vibe: a thing that happens in the system, at a moment you could point at afterward. A subject is the record the decision is about. One record type, named. A decision that is sometimes about a person and sometimes about a company is two decisions. A question is what is being decided, phrased so it has answers. It has to be closed. “How good is this lead?” is not closed. “Should GTM Lab route this person to a seller now?” is. A moment is when the answer has to exist by. This is the part everyone skips, and it is the part that determines almost every design choice downstream.

Put together, GTM Lab's version reads: when a person submits the demo request form, decide whether GTM Lab should route this person to a seller now, before the record converts. That sentence is boring, and that is the point. Nobody can hear three different things in it.

One card, one decision

The request that started this contained at least three decisions, and they only look like one because they happen in the same ten seconds. Whether to route this person to a seller is one. What the first response should say is another, and it is a genuinely different decision with a different owner and a different failure mode. Whether this person's company is worth pursuing as an account is a third, and it is not even about the same record.

Bundling them feels efficient. It is the single most common way a decision system becomes impossible to change: six months later somebody wants to adjust the routing threshold and discovers that the follow-up email copy is wired to the same rule, so the change has to go through two teams and a copy review. Write one card per decision. Cards can reference each other. They should not contain each other.

Watching the split happen

Priya Shah submits GTM Lab's demo request form at 9:14 on a Tuesday, with a message about whether the product handles multi-region deployments.

One decision fires: should this person be routed to a seller now? The trigger is the form submission. The subject is her person record. The moment is before the record converts, because the first pillar established that conversion is a record-handling event that should not be racing ahead of a judgment nobody has made yet.

A second decision exists and is not on this card: what the first response says. It has its own trigger, which is the outcome of the first decision, not the form submission. That dependency is worth noticing. Decisions chain, and a chained decision waits.

Carry this into your business

Take the last thing somebody asked you to automate and write the four parts down. Most requests survive it. The ones that do not are usually two decisions in a trench coat, and finding that out now costs an afternoon instead of a rebuild.