Automate PandaDoc Status Tracking with Make.com Webhooks

Manual document follow-up is one of the most expensive invisible costs in HR operations. According to Asana’s Anatomy of Work research, knowledge workers spend a significant portion of their day on low-value coordination tasks — and checking whether a document has been signed sits squarely in that category. This case study shows how one HR team eliminated that burden entirely by connecting PandaDoc webhooks to Make.com™, achieving real-time document status visibility across their entire hiring pipeline.

For the broader strategic framework behind this automation, see the HR document automation strategy guide that anchors this series. For a parallel deep-dive on visibility tooling, see our guide on real-time HR document tracking.


Snapshot: Context, Constraints, and Outcomes

Factor Detail
Organization Regional healthcare system, 400–600 employees
Primary stakeholder Sarah, HR Director
Baseline problem 12 hours/week consumed by manual document status checking and follow-up across offer letters, onboarding packets, and policy acknowledgments
Constraints No dedicated IT support; compliance audit requirements for timestamped document events; existing PandaDoc Business plan
Approach PandaDoc webhooks → Make.com™ Custom Webhook trigger → JSON parser → event-type filters → parallel logging and CRM/HRIS update routes
Build time One day (initial build and testing)
Outcome 6 hours/week reclaimed; average document-to-completion time reduced 60%; zero missed-signature incidents in 90-day post-launch window

Context and Baseline: What Manual Document Tracking Actually Costs

Sarah’s team was managing a high-volume hiring cycle — 40 to 60 active candidates at any point, each requiring at least three sequenced documents: offer letter, background authorization, and onboarding packet. Every document sat in PandaDoc. Every status check required a human to open the platform, scan the dashboard, and decide whether to send a follow-up.

That process repeated across the team multiple times daily. Conservatively, 12 hours per week were consumed by this coordination loop — time that produced no document, no decision, and no candidate experience value. It was pure overhead.

The downstream consequences were measurable. When signatories weren’t followed up promptly, start dates slipped. When policy acknowledgments were delayed, compliance windows closed. SHRM research consistently shows that unfilled positions cost organizations in productivity and opportunity — and slow document pipelines extend those costs directly. The problem wasn’t effort. It was architecture: a deterministic, rules-based task (check status, send reminder if unsigned after X hours) was being handled by a human instead of a system.

Parseur’s Manual Data Entry Report places the annual cost of manual document handling at approximately $28,500 per employee — a figure that reflects the compounding cost of low-value repetition across an entire work year. Sarah’s situation was a textbook instance of that cost made visible.


Approach: Webhook Architecture Over Polling

The architectural decision came first. Two approaches exist for connecting PandaDoc status data to external systems: polling (scheduled checks against the PandaDoc API at set intervals) and webhooks (event-driven pushes that fire the instant a status changes). Polling introduces lag, consumes API rate limits, and requires scheduled runs. Webhooks are instantaneous, resource-efficient, and require no scheduled trigger.

The design chosen was a four-layer Make.com™ scenario:

  1. Custom Webhook trigger — listens for all incoming PandaDoc event payloads
  2. JSON parser module — structures the raw payload into addressable data fields (document ID, document name, recipient email, event type, timestamp)
  3. Router module with event-type filters — branches the flow by event type so high-signal events (Signed, Completed) and low-signal events (Viewed, Sent) route to separate action chains
  4. Parallel action modules — Route A writes every event to a timestamped compliance log; Route B updates the HRIS and sends a Slack notification only on Signed/Completed events

This design choice — separate routes for logging and notification — was the difference between an automation that becomes noise and one that stays trusted. For more on building compliance-focused document automation, see the dedicated satellite in this series.


Implementation: Step-by-Step Configuration

Phase 1 — Define Tracked Events and Data Requirements

Before touching PandaDoc or Make.com™, Sarah’s team documented exactly which status transitions mattered and what data each downstream system needed. This planning step prevented scope creep during build.

  • Tracked events: Document Sent, Document Viewed, Document Signed, Document Completed, Document Declined, Document Expired
  • Required payload fields: document_id, document_name, recipient_email, event_type, event_timestamp, template_name
  • Downstream targets: Google Sheets (compliance log, all events); HRIS (update candidate record on Signed/Completed); Slack (HR channel alert on Signed/Completed and Declined/Expired)

Phase 2 — Configure PandaDoc Webhooks

Inside PandaDoc workspace settings, navigate to the Integrations → Webhooks section. Create a new webhook endpoint. At this stage, the Make.com™ listener URL is not yet available — leave the URL field open and proceed to Phase 3 to generate it. Select all six event types identified in Phase 1. Set the webhook to Active.

Important: PandaDoc webhooks fire for all documents in the workspace by default. If the workspace contains non-HR documents, add a filter condition in Phase 4 to scope the Make.com™ scenario to HR-relevant templates only.

Phase 3 — Build the Make.com Scenario and Generate the Listener URL

In Make.com™, create a new scenario. Set the trigger module to Webhooks → Custom Webhook. Save the module — Make.com™ generates a unique HTTPS listener URL. Copy that URL and paste it into the PandaDoc webhook configuration from Phase 2. Save both.

Test the connection by changing the status of a test document in PandaDoc. Make.com™ will catch the payload and display the raw data structure. This auto-detection step is critical — Make.com™ uses the sample payload to map all available fields for use in downstream modules.

Phase 4 — Parse and Filter the Payload

Add a JSON module immediately after the webhook trigger. Map it to the body of the incoming payload. All PandaDoc fields — document_id, event_type, recipient details, timestamps — are now individually addressable throughout the scenario.

Add a Router module next. Create two routes:

  • Route A (High-Signal): Filter condition: event_type equals ‘document_signed’ OR event_type equals ‘document_completed’ OR event_type equals ‘document_declined’ OR event_type equals ‘document_expired’
  • Route B (All Events — Log Only): No filter condition; catches every event for compliance logging

This is the leverage point. Every document event goes to the compliance log. Only actionable events reach the HRIS and Slack. The signal-to-noise ratio in downstream systems stays high indefinitely.

This same filtering discipline applies across automated offer letter workflows and NDA automation with PandaDoc and Make — the router-and-filter pattern is reusable across every document type.

Phase 5 — Configure Action Modules

Route B (Compliance Log): Add a Google Sheets → Add Row module. Map columns: Timestamp (event_timestamp field), Document ID, Document Name, Recipient Email, Event Type, Template Name. Every status change for every document writes a permanent, timestamped row. No manual record-keeping required.

Route A — HRIS Update: Add an HTTP or native HRIS module to update the candidate’s record. Map document_id to the corresponding candidate record. Set the status field to the event_type value. This keeps the HRIS current without any manual entry — directly addressing the class of errors documented in our guide on error-proofing HR document workflows.

Route A — Slack Notification: Add a Slack → Send Message module. Compose the message dynamically: “Document [document_name] has been [event_type] by [recipient_email] at [event_timestamp].” Target the HR operations channel. For Declined and Expired events, add a second Slack message to a separate escalation channel.

Phase 6 — Add Error Handling

Add an error handler route to the scenario. Configure it to send a Slack alert to a technical channel whenever a module fails. Common failure points are HRIS authentication timeouts and Google Sheets quota limits during high-volume periods. The error handler ensures no status change is silently lost.

Activate the scenario. Set the scheduling to run continuously (webhook-triggered, not scheduled). The scenario is now live.


Results: Before and After

Metric Before After
Hours/week on document status checks ~12 hours ~0 hours (automated)
Average document-to-completion time Baseline 60% reduction
Missed-signature incidents (90 days post-launch) Multiple per month Zero
Compliance log completeness Manual, incomplete 100% automated, timestamped
HRIS update lag (post-signature) Hours to days (manual) Under 60 seconds (automated)
Build time One day

The six hours reclaimed weekly translated directly into strategic HR capacity. Sarah’s team redirected that time toward candidate experience improvements and manager coaching — work that required human judgment and couldn’t be automated. McKinsey Global Institute research identifies this type of reallocation — from low-value coordination to high-judgment work — as the primary driver of automation ROI in knowledge-work environments.


Lessons Learned: What We’d Do Differently

1. Build the compliance log first, not last

The compliance log was added in Phase 5 as a Route B action. In retrospect, it should be the first module after the JSON parser — a universal capture that runs before any filtering. That sequencing guarantees no event is ever dropped, even if a filter misconfiguration temporarily breaks a downstream route.

2. Test Declined and Expired events explicitly

During initial testing, only Signed and Completed events were tested against the filter logic. Declined and Expired events were assumed to work correctly. They didn’t — a typo in the event type string caused them to bypass the high-signal route. Explicit testing of every event type against every filter condition is non-negotiable.

3. Scope the webhook to document templates, not the whole workspace

PandaDoc fires webhooks for every document in the workspace, including sales proposals and vendor contracts that HR doesn’t own. Adding a template-name filter in Make.com™ from day one would have prevented the noise that appeared in the compliance log during the first two weeks. Scoping by template is standard practice in HR workflow automation and should be treated as a default, not an afterthought.

4. Document the scenario for the next administrator

Make.com™ scenarios are visually intuitive to their builder and opaque to everyone else. After launch, add notes to every module explaining what it does and why the filter condition is set as it is. When Sarah’s team eventually onboarded a new HR coordinator, undocumented scenarios created a three-hour re-learning session that a five-minute annotation habit would have prevented.


Reusability: The Same Architecture Scales Across Document Types

The scenario Sarah’s team built — webhook trigger, JSON parser, router, event filters, parallel action routes — is not offer-letter-specific. The same architecture handles:

  • Onboarding packets: Route completion events to HRIS to trigger IT provisioning and benefits enrollment workflows
  • Policy acknowledgments: Route signed events to the compliance log with a policy-version tag for audit readiness
  • NDAs: Route completed events to the vendor management system, closing the loop on contractor onboarding
  • Background check authorizations: Route signed events to the background check vendor’s API trigger

Each document type gets its own router branch. The compliance log captures all of them in a single sheet. One scenario, full pipeline visibility. This reusability is precisely why Forrester consistently identifies integration architecture — not individual tool selection — as the primary determinant of long-term automation ROI.

For a comprehensive view of how this fits into your broader automation investment, see our analysis of HR document automation ROI. To understand how this architecture eliminates the manual data entry that creates downstream errors, see the guide on eliminating manual data entry in HR.


Frequently Asked Questions

What is a PandaDoc webhook and how does it work with Make.com?

A PandaDoc webhook is an outbound HTTP notification that fires automatically whenever a document changes status. Make.com™ provides a unique listener URL that receives that payload instantly, allowing downstream actions — CRM updates, Slack alerts, spreadsheet logs — to trigger without manual checking or scheduled polling.

Which PandaDoc document events should I track?

For HR workflows, track Document Sent, Document Viewed, Document Signed, Document Completed, Document Declined, and Document Expired. Signed and Completed events trigger operational updates; Declined and Expired events trigger exception-handling and escalation routes.

Do I need coding skills to build this automation?

No. The entire integration is built inside Make.com™’s visual scenario editor. No custom code is required. Teams with no prior automation experience typically complete the initial build in four to six hours.

How do I prevent notification overload in my CRM or Slack channel?

Use Make.com™ filter modules immediately after the JSON parser, set to pass only on high-value status values like ‘document.signed’ or ‘document.completed’. Route low-signal events like ‘Viewed’ to a log separately without triggering notifications.

Is this approach compliant for sensitive HR documents?

Yes. PandaDoc maintains a tamper-evident audit trail for every document event. The Make.com™ scenario adds a second layer by logging every webhook payload with a timestamp. That dual-log structure satisfies most HR compliance requirements for offer letters, NDAs, and policy acknowledgments.

What happens if a webhook payload fails to deliver?

Make.com™ logs failed webhook deliveries in the scenario’s execution history. Configure an error handler route to send a Slack alert when a downstream action fails, preventing silent data gaps.

Can one Make.com scenario handle multiple document types?

Yes. A single scenario scaffold with a Router module handles all PandaDoc document types by branching on document template name or custom field value, keeping scenario count low and maintenance straightforward.

How long does it take to see ROI from this automation?

ROI is immediate in the first week. Teams that previously spent time manually checking document dashboards recover that time entirely once the automation is live.