How to Use n8n with ._Template 22 Proposal Viewed Notify
You send a proposal, then you wait. The prospect opens it at 9:47pm, reads it twice, forwards it to a colleague — and you find out none of this. By the time you follow up two days later with a generic
You send a proposal, then you wait. The prospect opens it at 9:47pm, reads it twice, forwards it to a colleague — and you find out none of this. By the time you follow up two days later with a generic "just checking in," the moment of peak intent has passed. The single highest-leverage signal in any sales cycle is the prospect is looking at your proposal right now, and most teams have no way to capture it. This workflow fixes that: an n8n automation that fires the instant a proposal is viewed and pushes a real-time notification to the person who can act on it.
The Problem: Intent Signals Die in Transit
Proposal-tracking tools (DocSend, PandaDoc, Google Docs analytics, a tracked PDF) all know when a document is opened. The problem is what happens next: that event sits in a dashboard nobody is watching. Your sales rep is in a meeting, your founder is heads-down in code, and the "viewed" event decays into a stale row in an analytics tab.
The cost is measurable. Follow-up sent within an hour of a proposal view converts dramatically better than follow-up sent the next day, because you are reaching the buyer while your pricing, scope, and value are still loaded in their working memory. Every hour of delay is a discount you didn't mean to give. Manual monitoring doesn't scale past a handful of deals, and hiring someone to refresh a dashboard is absurd. This is exactly the kind of glue work n8n exists to remove.
The Solution: An Event-Driven Notify Pipeline
The pattern is simple and durable: capture the view event → enrich it with deal context → route a notification to the right human on the right channel. In n8n this is a single workflow triggered by a webhook, and it runs in under a second per event with zero polling.
The core nodes you'll wire together:
- Webhook — receives the "proposal viewed" event from your document tool.
- Set / Edit Fields — normalizes the payload into clean variables (prospect name, document ID, timestamp).
- HTTP Request — looks up the associated deal/contact in your CRM to add context.
- IF — filters noise (ignores your own internal opens, dedupes repeat views).
- Slack / Send Email / Telegram — delivers the alert.
Everything is event-driven, so there is no cron job hammering an API and no rate-limit risk. The document tool tells n8n the moment something happens, and n8n does the rest.
Step-by-Step Setup in n8n
1. Create the Webhook trigger. Add a Webhook node, set the HTTP method to POST, and give it a path like proposal-viewed. n8n generates a production URL such as https://your-instance/webhook/proposal-viewed. Copy it. In your proposal tool (DocSend, PandaDoc, or a custom tracking pixel), register that URL as the destination for its "document viewed" event or outbound webhook.
2. Normalize the payload. Add a Edit Fields (Set) node right after the webhook. Different tools send wildly different JSON, so map their fields to a stable internal shape. For example, set prospect_email to {{ $json.body.viewer.email }}, document_name to {{ $json.body.document.title }}, and viewed_at to {{ $json.body.timestamp }}. From here on, downstream nodes reference your clean names, not the vendor's schema — which means swapping tools later only touches this one node.
3. Enrich with CRM context. A raw email address isn't actionable; the deal it belongs to is. Add an HTTP Request node (or the native HubSpot / Pipedrive node) to query your CRM by prospect_email. Pull back the deal owner, deal size, and pipeline stage. Now your notification can say "$24k Acme deal, owned by Sara" instead of "someone opened a file."
4. Filter out noise. Insert an IF node. Add conditions to drop events you don't care about: exclude internal domains ({{ $json.prospect_email }} does not contain @yourcompany.com), and skip records where the CRM lookup returned nothing. Optionally, add a Code node or a small NoOp/data store check to dedupe — a prospect who scrolls back and forth can fire the event five times in a minute, and you want one alert, not five.
5. Route the notification. On the "true" branch of the IF, add your delivery node. For a sales team, the Slack node posting to a #deals-live channel works best — set the message to something like: 🔥 {{ $json.prospect_name }} is viewing "{{ $json.document_name }}" right now. Deal: {{ $json.deal_size }}. Owner: {{ $json.owner }}. Reach out now. For solo founders, the Telegram or Send Email node to your personal inbox is faster to check on mobile.
6. Test and activate. Use n8n's Listen for Test Event button on the webhook, then open a tracked proposal yourself to fire a real payload. Confirm each node's output in the execution log, fix any field mappings, then toggle the workflow to Active. Production webhooks only fire when the workflow is active — a common gotcha we'll revisit below.
Benefits: What This Actually Buys You
Speed to follow-up. You go from "found out two days later" to "pinged them within five minutes." That timing alone is often the difference between a closed deal and a ghosted thread.
Context, not just alerts. Because the workflow enriches from your CRM, every notification is decision-ready. The rep doesn't have to go look anything up — they see the deal, the value, and the owner in one line.
Zero maintenance overhead. Event-driven means no polling, no scheduled runs eating your API quota, and no dashboard anyone has to babysit. The workflow sits idle at zero cost until a real signal arrives.
Tool-agnostic. The normalize-in-one-node pattern means you can switch from DocSend to PandaDoc, or add a second document source, without rebuilding anything downstream. One Set node absorbs the change.
Composable. Once the view event is flowing through n8n, you can branch it: log every view to a Google Sheet for pipeline analytics, auto-create a follow-up task in your CRM, or trigger a nurture sequence — all from the same trigger.
Common Pitfalls (and How to Avoid Them)
The workflow isn't active. The single most common failure. Test executions work while you're editing, but the production webhook URL is dead until you flip the workflow to Active. If events stop arriving, check this first.
Duplicate-view spam. Document tools fire an event on every open, and prospects re-open proposals constantly. Without a dedupe step your team learns to ignore the channel. Add an IF condition or a short-window suppression (store the last-alerted timestamp per prospect in a Data Store or external key-value, and skip if the last alert was under, say, 30 minutes ago).
Alerting on your own opens. When you QA a proposal or preview it before sending, you'll trigger the webhook and cry wolf. Always filter internal email domains in the IF node.
Fragile field references. Reaching deep into {{ $json.body.data.attributes.viewer }} in every node means one schema tweak from the vendor breaks the whole chain. Centralize all raw-payload access in the first Set node and reference your clean fields everywhere else.
No error handling on the CRM lookup. If the prospect isn't in your CRM yet, the HTTP Request node can error and halt the run — so you get no alert at all, which is worse than a context-light one. Set the node's "Continue On Fail" option and let the IF branch handle the empty result gracefully, still sending a basic notification.
Unsecured webhook. Your webhook URL is public. Add an authentication check — validate a shared secret or signature header from the sending tool in an early IF node — so random traffic can't inject fake "viewed" events into your sales channel.
Wire this up once and the highest-intent moment in your entire funnel stops slipping past you. The proposal gets opened, and before the prospect has finished reading page two, the right person already knows to reach out.