Stalled signature detection

Most revenue teams discover a stuck signature only when someone asks for a status update. By then, the envelope may have sat with a counterparty for a week while the quarter clock runs down. Stalled signature detection watches active signing workflows against expected progress windows and raises an alert when movement stops, so deal owners can chase signatures before delay becomes default.

The use case is narrow by design. It does not replace legal review, authority checks, or anomaly scoring on who signed. It answers one operational question: has this envelope moved within the time we expect at this stage? When the answer is no, the system surfaces envelope ID, days stalled, and the escalation rule ID that fired. When the workflow is complete or cancelled, the alert payload is empty and monitoring stops.

A signature workflow is stalled when its current state persists longer than a configured threshold. Thresholds are usually stage-specific, not one global number. Waiting on the first signer after send might warrant a 48-hour nudge; waiting on a CFO after three reminders might warrant escalation at five business days.

Typical stall signals include:

• Sent, no opens — envelope delivered but no recipient has viewed it.
• Viewed, not signed — at least one required signer opened the document but has not completed their action.
• Partial completion — some signers finished; one or more required parties have not.
• Internal hold — routing paused inside your org (legal review, approver queue) beyond the SLA for that step.

The detector reads workflow state from your signing platform or CLM, compares last_activity_at (or equivalent) to now, and evaluates rules tied to envelope status and routing order. It does not infer intent. A signer on vacation looks the same as a signer who forgot until someone follows up.

DocuSign, Adobe Sign, Ironclad, and Salesforce each expose enough envelope or agreement metadata for this pattern, though field names and event models differ. DocuSign and Adobe Sign emphasize envelope status and recipient action timestamps. Ironclad adds workflow stage and task ownership inside CLM-native flows. Salesforce often holds the deal owner on the opportunity while signature status lives on a related envelope or agreement record, so the escalation target usually resolves through CRM linkage rather than the e-sign object alone.

Implementation follows a poll-or-webhook loop plus rule evaluation.

1. Ingest state — On a schedule (every 15–60 minutes) or via platform webhooks (envelope-sent, recipient-completed, envelope-declined), pull active envelopes that are not terminal (completed, voided, expired).
2. Compute dwell time — For each open envelope, calculate days (or business days) since the last meaningful state change: sent, viewed, signed, routed, or reminder sent.
3. Match rules — Apply escalation rules keyed by document type, deal size, counterparty tier, or signing order. Example: MSA + enterprise + waiting on counterparty signatory 1 → escalate at 3 business days.
4. Emit alert — When a rule matches, produce a structured alert. When the envelope completes or is voided, clear pending alerts and return an empty result for that workflow.

A representative alert body:

{
  "envelope_id": "abc-123-def",
  "days_stalled": 4,
  "escalation_rule_id": "rule_counterparty_msa_t3",
  "current_status": "waiting_on_signer",
  "pending_signer": "[email protected]",
  "deal_owner_id": "005XXXXXXXXXXXX"
}

escalation_rule_id matters for tuning. Without it, teams cannot tell whether a flood of alerts comes from one aggressive rule or many moderate ones. days_stalled gives the deal owner immediate context for the chase ("We sent this four days ago with no signature") without opening the admin console.

Escalation delivery stays lightweight: Slack or Teams message, email to deal owner, CRM task, or queue entry in a legal ops inbox. The automation does not send legal threats or auto-cancel envelopes unless you explicitly configure that elsewhere. Approval summary generation may run upstream when an envelope is created; stalled detection runs downstream on execution timing.

Stalled signature detection sits in the monitoring and operations layer. It assumes envelopes are already correctly structured and sent to authorized signers.

| Concern | Related use case | Relationship | |--------|------------------|--------------| | Wrong signer or suspicious pattern | Counterparty signing anomaly detection | Anomaly detection flags trust and fraud signals; stall detection flags elapsed time | | Parsing who must sign | Signature block extractor | Extractor populates signers at draft time; stall detection watches them after send | | Authority to bind | Signatory authority verification | Authority checks reduce send errors; stall detection assumes send was valid | | Pre-send approvals | Approval summary generation | Summaries document what was approved; stall detection starts once execution is in flight |

Together, these use cases cover prepare, verify, send, and monitor. Stall detection is the monitor that closes the loop on speed: shrinking the gap between "waiting" and "someone noticed."

DocuSign — Envelope API and Connect webhooks provide status, statusChangedDateTime, and per-recipient signedDateTime / deliveredDateTime. Map envelopeId to CRM opportunity via a custom field or middleware. Connect reduces polling lag; polling remains a useful backstop when webhooks drop.

Adobe Sign — Agreement REST API exposes agreement state and participant sets. expirationTime and reminder history help distinguish passive waiting from active nudging already attempted. Link agreements to Salesforce opportunities through Adobe Sign for Salesforce or your integration layer.

Ironclad — Workflow records carry stage names and assignees. Stall logic often keys off workflow stage dwell rather than raw e-sign timestamps alone, because Ironclad bundles review, approval, and signature. Escalation may route to the workflow owner before the external signer when the bottleneck is internal.

Salesforce — Rarely stores full signature telemetry natively unless you use a managed package or sync job. Pattern: mirror envelope status to a custom object (Signature_Envelope__c) with Last_Activity_Date__c, Status__c, and lookup to Opportunity. Flow or Apex evaluates stall rules; the alert references Salesforce IDs the rep already knows. Deal owner remains the human who chases; the alert only ensures they know which envelope and how long.

The measurable outcome is speed: fewer deals lost to silent signing delays, shorter average time from send to fully executed, and earlier intervention on the long tail of envelopes that would otherwise complete on day 14 instead of day 4.

Stall detection does not auto-sign, auto-approve, or replace the deal owner's follow-up. Legal and sales still own the relationship. The system removes the need to manually scan signing dashboards or ask "any update on the Acme MSA?" in standup. When the workflow completes, monitoring stops and alerts go quiet, which prevents alert fatigue on closed business.

Practical success metrics:

• Median time to first chase after a stall begins (target: same business day as rule fire).
• Percent of stalled envelopes resolved within one escalation cycle (owner acted; signature received or envelope voided and resent).
• Reduction in quarter-end surprise — envelopes still open with <72 hours to close.

Start with one document type and one counterparty-facing rule. Log every fired escalation_rule_id for two weeks before widening thresholds. Tighten rules that fire too often; loosen rules where legitimate delays (multi-party boards, holiday weeks) produce noise. The goal is a reliable early warning, not a second inbox full of false alarms.

[REDACTED]