Jacomini

My honest read is that retrofitting interpretation onto existing PDF workflows is possible but limited — you're always working with incomplete signal. The format shapes what's observable, and static documents were never designed to be instrumented. That said, I don't think the answer is forcing everyone to web-based proposals. The real leverage is probably in the interpretation layer sitting above the format — something that aggregates whatever signals exist, whether from document tracking, email open data, CRM activity, or conversation intelligence, and surfaces the pattern rather than the raw event. What you described earlier — a second stakeholder appearing, the original contact going quiet, someone returning specifically to the pricing section — those signals already exist in most stacks. They're just not being read together. That's the problem worth solving. Not replacing the PDF. Connecting the dots that are already there. Really valuable conversation. Learned something here.

That's exactly the right question — and it points to a layer that most operations haven't instrumented yet. What you're describing has a name in the tooling market: proposal intelligence. The gap between sending a proposal and getting a response is no longer unobservable — it's just that most teams are still sending static PDFs and getting nothing back. Tools like Qwilr track buyer behavior at the block level inside web-based proposals — which sections they read, how long they spent on pricing versus scope, whether the proposal was forwarded internally, and real-time notifications when engagement stalls. DocBeacon takes a similar approach focused on analytics depth, including heatmaps and an AI-generated engagement score that ranks deals by real buyer interest so you can prioritize follow-ups without rep input. HYM Gluo CRM The move from static PDF to a trackable web-based proposal link is what closes the blind spot you're describing — without requiring the rep to log anything. In our case, we're not there yet. But the architecture I'm building — structured CRM, AI transcription, SDR automation — creates the conditions where adding a proposal intelligence layer actually makes sense. Without clean upstream data, even the best post-proposal signal is hard to act on. To answer your original question: I think it's solvable, it just requires treating the proposal as an instrumented touchpoint rather than a document you send and wait on. The tooling exists. The process change is harder. What signals have you found most predictive — time on pricing section, repeat opens, or something else entirely?

In our operation, before the proposal goes out I have solid data — lead source, order volume, marketplaces, current tool, declared pain, objections raised during the demo. That side of the funnel is reasonably instrumented. Once the proposal is sent, visibility drops significantly. When a deal stalls or goes dark, the explanation is almost always reconstructed from the closer's memory, not from actual data. I do track loss reasons with detailed categories, and that part works. But the window between sending the proposal and the final decision is still a real blind spot. My read is that it's a process problem before it's a tooling problem. The tool won't fix it if the closer doesn't have the habit of logging each post-proposal interaction in real time. I'm addressing this now by implementing a more structured CRM and AI-powered meeting transcription — the goal is to have that data flowing without depending on each closer's individual discipline. My hypothesis is that most operations accept this blind spot as a given rather than treating it as a problem worth solving. What's been working for you?

Sorry 🤣

I've had more success with automated WhatsApp messaging (using the official API to avoid blocks). My conversion rate via email is almost zero.