See where your Docusign signing process actually stalls

Build me an app that answers the question Docusign's own reporting is too slow to answer: where does our signing process actually stall? It is a single analytics dashboard I open, choose a date range, and read. The audience is a sales ops or revenue ops manager who wants to know which agreements drag, which reps let deals rot, and whether the holdup is the customer or our own countersigner.

At the top of the app, put a date range control with quick presets for last 30 days, last 90 days, and last quarter, plus a custom range. Next to it, a toggle to compare against the immediately preceding period of the same length. The whole dashboard recomputes against whatever range is selected.

To build the dataset, use Docusign List Envelopes filtered by the selected date range, pulling completed envelopes, ones still in flight (sent, delivered, signed), and declined and voided ones so the failure rates are real. List Envelopes pages with count and start_position and tops out around 1000 per page, so page through until the result set is exhausted. For each envelope call Get Envelope Audit Events to reconstruct the real timeline: when it was sent, when each recipient viewed it, and when each one signed. Use List Recipients on each envelope for routing order positions, recipient names, and signer email addresses. Use List Templates, and Get Template where more detail is needed, to resolve template ids on envelopes into readable template names.

Caching is a hard requirement, not a nicety. Docusign allows roughly 3,000 API calls per hour per account, and reconstructing a few months of history costs an audit events call and a recipients call per envelope, so a naive refetch will be slow and will blow through the rate limit. Store the fetched envelope timelines and the computed metrics in the app's own storage keyed by date range, and serve from cache when I reopen the app. Only fetch envelopes that are not already cached, refresh the in flight ones since their status changes, and give me an explicit refresh control with a visible note of when the data was last pulled. Show progress while a first large backfill runs rather than a blank screen.

The headline metrics across the top: median days to fully signed, 90th percentile days to fully signed, the viewed but not signed rate (envelopes where at least one recipient opened it but it never reached completed), the void and decline rate, and average hours an envelope sits at each position in the routing order. That last one is the most important number in the app. Compute it from the audit events by measuring the gap between when a routing position became active and when that position's recipient completed their action, then show it as a small bar chart by position, so I can immediately see whether position two, usually our own countersigner, is the bottleneck.

Below the headline numbers, three breakdown tables, each showing median days to completion, envelope count, and completion rate: by template, by sender (the envelope's sending user), and by counterparty company derived from signer email domains. For the counterparty grouping, take signer email domains from List Recipients, ignore our own domain and common free mail domains like gmail.com and outlook.com, and group the rest by domain so each row is effectively one customer company.

Clicking any row in any of the three tables drills into the individual envelopes behind that number. The drill-down shows one row per envelope with subject, status, sender, days elapsed or days to complete, the routing position it is currently waiting on, and the recipient list with each person's status and timestamps from List Recipients. Sort by slowest first by default, since the point is to find the specific deals dragging the average. Use Get Envelope if you need any envelope detail the list call does not return.

When the comparison toggle is on, every headline metric and every breakdown row shows the previous period's value alongside the current one with the direction and size of the change, so I can tell whether things are getting better or worse. Make improvements and regressions visually distinct.

Add an "Explain this period" button that kicks off a background agent over the already computed metrics rather than the raw envelope data. The agent reads the headline numbers, the per position dwell times, the three breakdowns, and the previous period comparison, then writes a short plain English analysis, a few paragraphs at most, naming the two or three biggest bottlenecks, calling out the specific templates, senders, or customer companies responsible, and saying what changed since last period. Its output lands back in the app in a panel under the metrics with a timestamp, and past explanations stay readable so I can look back at what it said last month.

Give me a button to push the current filtered summary table into a Google Sheet using Append Values, so I can drop it into my monthly ops review deck. Let me pick or paste the spreadsheet, and append rows carrying the date range, segment name, envelope count, median days, 90th percentile days, and completion rate, with a run date on each row so successive months stack up in the same sheet.

Keep the whole thing on one screen where possible, with the drill-down as a panel or overlay rather than a separate page I have to navigate back from. Show loading and empty states honestly. If a segment has too few completed envelopes for a median to mean anything, say so on the row instead of showing a misleading number.