Clients start the records upload and abandon it halfway through

A client who opened the link, signed in and uploaded 3 of 11 documents did not lose interest between file 3 and file 4. Something stopped them, it happened at a specific step, and that step is recordable. Every firm that has instrumented this properly finds the drop concentrated in 2 or 3 places rather than spread evenly, which is what makes it fixable.

The diagnosis fails when abandonment is treated as an attitude. Staff report that clients "never use the portal", the firm responds with training material and a friendlier reminder, and the session data — which nobody has looked at — shows sessions starting at a healthy rate and dying at authentication.

Instrument the 6 steps between the link and the last file

You need 6 timestamps per session, not a page-view count. Analytics tools measure pages; an upload funnel is measured in state transitions on the request item, and the useful ones are cheap to log server-side.

1. Link opened. The reminder was clicked and the page rendered, with device class and browser recorded.
2. Session authenticated. The client got past login, magic link or whatever gate stands in front of the list.
3. First file selected. The file picker returned something, which proves the client understood what to do.
4. First file stored. The upload completed server-side. The gap between selected and stored is where size, type and network failures live.
5. Each subsequent item stored, with elapsed time from the previous one. A 4-minute gap is a client hunting through a filing cabinet; a 12-second gap followed by nothing is a rejection.
6. Session ended, with items outstanding at that moment. Log whether the end was an explicit submit, a tab close or an idle timeout.

Five places a records upload dies

In rough order of how often they carry the drop once the funnel exists. Each has a distinct signature in the timestamps, which is why the instrumentation comes first.

The session expired while the client was hunting for a statement

Collecting records is not a 5-minute task. A client opens the list, uploads what is on the desktop, then goes to find the March statement, logs into a bank, waits for a one-time code, downloads a PDF and comes back 20 minutes later to a login screen. Whatever was selected but not yet sent is gone.

• Idle timeouts written for a banking app are wrong here. An intake session is long, low-risk and read-nothing: the client can only add files to their own engagement.
• Re-authentication must preserve state. Returning the client to the list at the item they were on costs an afternoon to build and recovers whole sessions.
• A token that expires silently is worse than one that expires loudly. A failed upload with no message reads as "this portal is broken" and ends the relationship with the tool.
• Which login method to use is a separate decision, argued in magic link or password for a client records portal. This page is only about the session dying while work is in progress.

A 1 MB default and a 413 the browser cannot show

Upload size is capped at more hops than most teams remember: the browser, the reverse proxy, the application framework, the storage client and any CDN in front. The proxy is the usual culprit. nginx documents a default client_max_body_size of 1m and returns 413 (Request Entity Too Large) above it, with the explicit warning that browsers cannot correctly display this error. A 6 MB scanned bank statement therefore fails with a blank page.

• Set the limit deliberately at every hop. A 12-page scanned statement at 300 dpi is comfortably into tens of megabytes; a phone photo of a receipt is a few.
• Catch the rejection client-side first. Check size and type in the browser before transfer, so the message names the file and the limit rather than failing after a 90-second wait.
• Say what to do next. "This file is 34 MB; the limit is 25 MB — send pages 1-6 and 7-12 separately" keeps the session alive.
• Watch the type filter. An accept list of PDF and JPEG rejects the HEIC images an iPhone produces by default, and the client sees their own photo refused with no reason given.
• Accepting a phone photo is not the end of it. An image that uploads perfectly can still be unusable downstream, which is a different failure — see why the extracted statement does not foot.

12 items in a fixed order is a request-list problem

When every session in a cohort stops at the same item number, the portal is working and the list is wrong. A client who cannot produce item 4 — the loan statement is with the broker, the stock count has not been done — is blocked from sending items 5 to 12, all of which are on their desk. The firm records 8 missing documents and chases them, and the client believes they were stopped from complying.

Two changes fix it. Allow partial submission with an explicit "I cannot provide this" state and a reason, which turns a silent stall into information the preparer can act on. Then shorten the list itself: a request list derived from what the previous period actually consumed is materially shorter than a standing template, an approach set out in generating the next request list from the last close.

Where the decision tree ends: change the capture, or change the list

Every branch resolves to one of 2 fixes, and knowing which one you are on stops a firm from redesigning the wrong thing. If the drop clusters at authentication, file handling or transfer, it is a capture fix: session length, limits, error messages, resumable upload. If it clusters at a specific item number or on the same 2 or 3 item types across unrelated clients, it is a request-list fix, and no amount of upload engineering will move it.

• Capture fix, laptop-dominated. Body limits, type filters, error text and a client-side pre-check. Usually days of work, and it recovers whole cohorts at once.
• Capture fix, phone-dominated. Chunked resumable upload, compression before transfer, and a flow that survives the screen locking.
• Request-list fix. Out-of-order upload, partial submission, a blocked state with a reason, and a shorter derived list.
• Neither, occasionally. Sessions that never start at all are a reminder and addressing problem instead — the decay described in clients who answer the first document reminder and ignore every one after it.

One thing this page deliberately does not settle is whether the portal should be the collection channel at all; that argument sits in email intake or portal upload for client records. What matters here is that a frustrated client always has a fallback, and both of the common ones leak: records emailed to a staff member never reach the engagement folder, and receipts sent over chat arrive with no client and no period. A portal that fails halfway does not stop records arriving. It moves them somewhere you are not measuring.

Rebuilding intake is a product problem more than an IT one: the surface the client touches twice a year has to work first time, on a phone, on a bad connection, with no support call available. That is the kind of work we scope as an MVP and product build for firms across accounting, tax and bookkeeping, and the rest of the client intake, chasing and portals cluster covers the request-list and state model it sits on.

• client portal
• document upload
• intake
• instrumentation