Someone Says, ‘We’re Building an AI Document Platform’—Is It a Real Project or an Early Idea?

Signals to watch

• The team explicitly says it is preparing to start a project
• The technology stack remains under evaluation
• The business use case, team roles, or timeline is becoming concrete
• The selection window is open but still requires human verification

You notice a message in a Telegram group:

“Our team is preparing to start a new project: a business-facing AI document-processing platform. We are still evaluating the technology stack, and the solution has not been decided.”

Note: This is an illustrative message assembled from common business-discussion patterns. It does not represent a real customer or conversation.

If you work in enterprise sales or business development, your first questions may be:

• Could this person become a customer?
• Should I message them immediately?
• What stage is the project in, and is there still time to participate?

Those questions arrive too early. With new-project Signals, the most dangerous move is reaching a conclusion before the evidence supports it. This article offers a framework for translating one vague group discussion into a decision you can verify and act on.

Why these opportunities are often discovered too late

A new project almost never enters a community as a formal request for proposal.

It appears indirectly first:

• Someone complains that the current approach is too slow or unreliable.
• A team debates whether it should build something internally.
• A technical lead asks whether anyone has used a similar architecture.
• Several departments disagree about which direction to choose.

Each sentence looks like ordinary conversation on its own. Read together, however, they show a team approaching a decision: a vendor, technology stack, or architecture will be selected. The window is still open, but it will not stay open indefinitely.

That makes these Signals difficult. They are distributed, ambiguous, and rarely come with a clear closing date. By the time someone writes, “We selected vendor A,” the opportunity window has already closed.

The most common beginner mistake: treating a symptom as the answer

When someone says, “We are building an AI document platform,” the sentence says almost nothing about project confidence. It is a symptom, not a verified plan.

It may be another way of saying, “Our document workflow is too slow,” or “The current solution no longer supports the business.” A symptom tells you where the discomfort is. It does not establish the root cause, the budget, or the right solution.

The beginner path looks like this: hear a symptom → map it to your product → begin pitching. That response treats an unverified need as an approved purchase plan. The other person may conclude that you did not understand the problem—or that you were only waiting for a chance to sell.

The better rule is simple: do not turn a symptom into a conclusion. Translate the discussion into questions that can be verified.

Translate a vague discussion into actionable questions

Do not begin with, “Would you like to buy this product?” Ask questions that expose the project structure instead:

Vague statement	Actionable question
“We are building an AI document platform.”	“What job must the platform complete first: document parsing, an approval workflow, or knowledge management?”
“We are still evaluating the technology stack.”	“Which approaches are under consideration? What has already been ruled out? When does the evaluation end?”
“The solution has not been decided.”	“Who is involved in the decision? Who approves the final choice? Is the primary criterion cost, performance, or delivery time?”
“The team is preparing to start.”	“Has the project been approved? Is there a preliminary budget or timeline?”

Answers to these questions create decision evidence, not a more polished sales pitch.

Decide whether a new-project Signal deserves follow-up

Not every “we want to build X” statement is a commercial opportunity. A useful filter separates core evidence from supporting evidence.

Core Signals: high weight, and each missing item should increase caution

• ✅ The team explicitly says it is starting a project—not “I have an idea,” but “we are preparing to start.”
• ✅ The project names a concrete business use case—“document-processing platform” is more specific than “AI platform.”
• ✅ Infrastructure or technology remains under active evaluation, so the selection window has not closed.
• ✅ The team structure is visible, with both a technical owner and a business stakeholder involved.

Supporting Signals: useful, but not decisive by themselves

• ✅ The discussion identifies a business pain and the limits of the current approach.
• ✅ It mentions a timeline or milestone, such as “we need a proposal next month.”
• ✅ A budget is mentioned, even if the team is still estimating it.

When at least three core Signals are supported, place the item in a human verification queue. With fewer than three, the highest-value action is still information gathering, not sales progression. This threshold is an editorial triage method—not a probability of purchase or a universal TOP Prospect product score.

What to do after a Signal becomes worth investigating

Suppose the evidence reaches the threshold: there appears to be a real project, and the evaluation window remains open. The next move is not sending a product link. It is completing three steps.

1. Preserve the complete evidence record

Record:

• The original message: preserve the exact wording rather than summarizing it as “the customer wants an AI platform.”
• Permitted context: retain the surrounding discussion so the message is not interpreted in isolation.
• Source information: identify the group, the author, and their observable participation history.
• Your reasoning: note which core Signals are supported and which point remains uncertain.

Why does this matter? If the judgment proves wrong, the record helps you improve the rule. If it proves useful, the evidence supports a more relevant human opening instead of a generic pitch.

2. Verify before intervening

Before making formal contact, verify:

• Whether the project appears to exist beyond one statement, using later permitted discussion as possible corroboration.
• The likely project stage and budget range.
• Which roles participate in the decision path.

The right sequence is to provide value before discussing your product. If the author says document processing is too slow, share a relevant implementation pattern or case—not an unsupported claim that your product solves everything.

3. Decide whether follow-up is immediate

• Clear Signal + at least three supported core conditions → mark it “pending follow-up,” complete human verification within 24 hours, and then decide whether to make contact.
• Ambiguous Signal + one or two supported core conditions → mark it “watch,” set a review date one or two weeks later, and observe related follow-up discussion.
• Clear statement but insufficient confirmation, such as a casual idea → save it as an informational record without placing it in the follow-up queue.

These statuses manage verification priority. They do not prove that a project is approved or that the author has become a customer.

A four-line record you can reuse today

The next time you see a new-project discussion, do not start with, “Is this a customer?” Write four lines first:

Observation: Someone in an Indonesia engineering group says, “We are preparing to build an AI document-processing platform.”
Business impact: If the project is real, it may involve a document-parsing engine or approval-system purchase.
Next deadline: The stack is under evaluation, and the selection window may close within two to four weeks.
Still to verify: Project approval, budget range, and decision owner.

If you cannot complete all four lines, the most valuable next action remains gathering information—not pushing the opportunity forward.

Conclusion

New-project Signals have unusually high variance. A correct judgment can let your team contribute early in a complete buying cycle. A weak judgment can waste hours on something a person mentioned casually.

The advantage is not contacting someone first. It is confirming quickly whether the object deserves continued attention. Do not turn a symptom into a conclusion, do not treat an ambiguous discussion as a confirmed requirement, and do not skip the evidence record.

Write the four lines first. Verify them, then decide whether the Signal should move to the next action.

---

This article extends the TOP Prospect scenario library. Continue with the complete methodology:

• How Telegram Group Messages Become Actionable Business Signals
• Keyword Rules or Semantic Judgment? A Stable Approach to Telegram Signal Extraction
• How to Score Business Signal Confidence: Source, Recency, Certainty, and Corroboration

TOP Prospect only analyzes messages from Telegram groups the user intentionally connects. It identifies candidate events in the user’s business language while retaining the original message, source, reasoning, and human review boundary. It does not read private chats, send messages automatically, or present a Signal score as proof of a deal.

Frequently asked questions

Does saying ‘we are building an AI project’ make someone a sales lead?

Not by itself. The statement only suggests that a project idea may be forming. Verify whether the project is approved, whether the stack is still under evaluation, who participates in the decision, and whether a timeline exists before moving it into a follow-up queue.

When is it appropriate to contact the author immediately?

When the use case, evaluation window, and team roles have support in the original message or later discussion, a human can verify the evidence and provide relevant value. Never treat a score or one group message as a confirmed purchase fact, and never automate outreach without review.

Does TOP Prospect automatically send sales messages to group members?

No. TOP Prospect only analyzes messages from Telegram groups the user intentionally connects. It preserves the original message, source, and reasoning and can suggest a next action; the user always decides whether and how to contact anyone.