Status & handling time

Each row also reports where the request sits in Mercura's processing lifecycle, the true handling time spent on it, and the timestamps around it:

• status — the lifecycle state: NEW, IN_PROGRESS, DONE, CANCELLED, PARSING, or PARSING_FAILED.
• active_seconds — the true handling time: the total active (engaged) seconds a user spent working the request before export. This is the exact per-request figure behind the in-app time per position metric — the same usage telemetry, read straight from that computation — and it counts only time the request was actively being worked. Defined for exported tenders only: null for orders, for requests not yet exported, and for exported requests with no recorded active time.
• first_opened_at — when a user first opened the request, or null if it was never opened.
• exported_at — when the request was first exported to your system, or null if it has not been exported yet.
• completed_at — the most recent completion / re-export. Unlike exported_at (set once, on the first export) this advances on every re-export.

Use active_seconds for handling time. To reproduce the time per position figure Mercura shows in-app, divide by positions_with_selection and aggregate as a pooled ratio across the rows:

Two details decide whether your number matches ours:

• Use positions_with_selection, not position_count. The metric measures effort per resolved line. Relevant positions that never got a selection are in position_count but were not worked, so including them understates the figure.
• Pool the totals; don't average the per-request ratios. AVG(active_seconds / positions_with_selection) weights a 3-position request exactly as heavily as a 300-position one. Request sizes are long-tailed — small requests are the most common — so the mean of ratios lands well above the pooled value. Both are legitimate statistics; only the pooled one is what the dashboard reports.

Per-selection effort is a different question, and selection_count is the right denominator for it:

Rows where active_seconds is null (orders, unexported requests, or requests with no recorded telemetry) must be excluded from both — they are unmeasured, not zero.

Do not use exported_at - first_opened_at as handling time. That span is wall-clock: a request opened on Monday and exported on Wednesday reads as two days even if only 20 minutes of work went in. It includes overnight and idle gaps, so it cannot tell you how long the user actually spent. active_seconds is the field that answers that. The timestamps are still useful for lifecycle reporting (when a request entered/left each state).