How to get clients to send readable documents instead of blurry phone photos

To get clients to send readable documents, tell them what a usable file is at the moment they are asked for it, check every upload the day it arrives rather than the day the work starts, and reply to a bad one with the specific fix. Most unreadable client uploads come from a phone photo taken in a hurry, sent through the only channel the firm offered, in reply to a request that never said what “readable” meant.

Almost everything written on this subject is aimed at the person holding the phone: how to scan with an iPhone, which app to use, how to hold the page flat. That advice never reaches the client, because the client is not searching for it. The firm is the one with the problem, and the firm has three things to control: how the request is worded, what the intake accepts, and how fast someone looks at what came in. This page covers the receiving end.

Why do clients send photos of documents instead of scans?

Because the phone is where the request arrived and the phone has a camera. A client reads the email on the train, finds the pay stub in a kitchen drawer that evening, and does the obvious thing. Ten years ago the obvious thing was a flatbed scanner. Now it is a photo, and the firm’s process has not caught up.

There is also a mismatch in what “scan” means. To the firm it means a flat, cropped, well-lit page at a resolution where every digit is legible. To most clients it means “a picture of it.” When a request says “please scan and send,” the client hears “please take a picture and send,” and does exactly that. They have not ignored the instruction. They have followed it.

Three more reasons come up whenever a firm sorts through its own unusable client document uploads:

• The request went out by email, so the reply came back by email, and the client’s mail app shrank the photo to fit an attachment limit. A file that was readable on the phone arrived as a blur.
• The document is a physical thing the client cannot easily reproduce: a passport, a paper ID card, an original letter. There is no PDF to download. A photo is the only option, and no one told them how to take a good one.
• The request lumped ten items into one line. “Send us your tax documents.” The client sent eleven photos in three texts, out of order, two of them of the same page.

The reasons are worth knowing because each one points at a different fix. A shrunk email attachment is a channel problem. A cut-off passport is an instruction problem. Eleven unlabeled photos is a request-structure problem. “Tell clients to scan properly” fixes none of them.

What makes a phone photo of a document unreadable?

Phone cameras are good. The photos still fail, for reasons that have little to do with megapixels. When a firm sorts its unusable uploads, the same handful of faults account for nearly all of them:

• Part of the page is out of frame. The account number is on the cut-off edge. The signature line is missing. The client photographed the part they thought mattered.
• Glare from an overhead light or a window sits across the one number the firm needs. The rest of the page is perfect.
• The page is at an angle, so the text at the far edge is smaller and softer than the text near the camera. Optical character recognition gives up on the far half.
• A shadow from the phone or the client’s hand falls across the middle of the page.
• The photo was taken in a dark room and the camera pushed the ISO up. The result looks fine as a thumbnail and turns to noise when zoomed.
• The file was compressed on its way over. Messaging apps and email clients recompress images, and a page that was readable on the phone loses the fine strokes that distinguish a 3 from an 8.
• The file is a screenshot of a photo, or a screenshot of a PDF viewer, with the phone’s status bar across the top and the page at a fraction of its size.
• The file is an HEIC that the firm’s system cannot open, so nobody can tell whether it is readable at all.

Phone photo versus scan document quality is mostly a question of geometry and light, not of the device. A phone in document mode, which detects the page edges, crops to them, corrects the angle, and boosts the contrast, produces something close to a flatbed scan. A phone in plain camera mode, held at an angle over a page on a kitchen table at night, does not. The client owns the same device in both cases. The difference is whether anyone told them to use the first mode.

Which is the point. The fault list above doubles as the checklist a good request has to head off, and the one a reviewer runs through in the first fifteen seconds of looking at an upload.

How to ask for a readable file the first time

Most of the answer to how to get clients to send readable documents is in the wording of the request. A line that says “driver’s license” gets a photo of a driver’s license, taken however the client happened to take it. A line that says what a good copy looks like gets a good copy far more often. The instruction goes next to the item, not in a paragraph at the top of the email that nobody reads.

The instruction has four parts, and each is one short clause.

Say which item, in the client’s words. “Your most recent pay stub” rather than “income verification.” “The letter USCIS sent you with the case number on it” rather than “receipt notice.” The client has to recognize the physical thing in their drawer.

Say what counts as a good copy. For a document that exists as a download, ask for the download: “the PDF from your bank’s website, not a photo of the screen.” For a paper document, say the four things that matter: all four corners in the frame, flat on a table, no glare across the text, readable at full size. Add “use your camera’s document or scan mode if it has one.” The iPhone Notes app and the Google Drive app both have one, and most clients have never opened it.

Say how many pages, and that each page is its own image. “The statement is usually three pages. Send all three, one photo each.” This single line removes most of the “page 2 of 3” chases from a firm’s week.

Say what file types work. If the intake accepts PDF, JPEG, PNG, and HEIC, say so, because a client who is refused on upload for a format they did not choose tends to give up rather than convert. If the intake does not accept HEIC, say that too, and say how to fix it. Apple’s own support page on HEIF and HEVC media gives the setting: Settings, Camera, Formats, Most Compatible switches the camera to JPEG. That one sentence in the request, or in the reply to the first HEIC that bounces, saves a round trip per iPhone client.

A worked example of a per-item request, for a mortgage file:

“Two most recent bank statements, all pages. Best: the PDF downloaded from your bank’s app or website. If you only have paper: photograph each page flat on a table, all four corners in frame, no glare. Files accepted: PDF, JPG, PNG, HEIC.”

That is fifty words. The client reads it on a phone in ten seconds and knows what to do. Compare it with “bank statements (2 months),” which is what most request lists say, and which produces the cut-off, glare-covered, page-one-only photo that started this page.

Two more things belong in the request. A single place to send everything, so the client is never choosing between replying to the email, texting a photo, and dropping a file in a shared folder. And a note that a photo is fine when it is the only option. Firms that demand “scans only” get clients who stall for a week looking for a scanner, then send a photo anyway. It is better to say what a good photo looks like than to pretend the phone does not exist.

The tax document checklist for clients works through the same wording rules for a tax firm’s list, where the wrong-year W-2 is the equivalent of the cut-off pay stub.

How to catch a blurry document upload the day it arrives

The most expensive unreadable upload is the one found late. A bank statement that arrives on the 3rd and is found cut off on the 3rd costs one message. The same statement found cut off on the 28th, when the preparer or the underwriter finally opens the file, costs a rushed reply, a client who has since moved on, and sometimes a missed deadline. The fix on the client’s side is the same in both cases. The cost is set entirely by when the firm looked.

So the operational rule is that “arrived” and “usable” are different states, and something has to move each upload from the first to the second on the day it lands. A tracker that only knows “arrived” tells the firm a file is ready when it is not. The tax document checklist page describes the four item states, requested, arrived, usable, and accepted, and the gap between the middle two is where every blurry photo lives.

The check itself takes under a minute per file, and anyone on the team can do it. Open the file at full size, not the thumbnail. Confirm it is the document that was asked for and not a neighboring one. Confirm all four edges of the page are present. Read the two or three fields the work depends on, the account number, the gross pay, the expiry date, and confirm each is legible. Count the pages against what the item asked for. Confirm the date range is the one requested. A file that passes every point is usable. A file that fails on any point goes back to the client the same day, with the reply described in the next section.

Who does the check matters less than when. At a two-person firm it is whoever opens the inbox. At a twenty-person firm it is an intake coordinator, and every new upload waits for a pass before it counts as received. The mistake is leaving it to the person who will use the document, because that person opens it last: the broker when the file is being packaged, the paralegal when the petition is being assembled, both weeks after the upload.

Automated review can front-run the human check. Software that reads each upload on arrival can classify what the document is, notice that a page is missing or a scan is too dark, and flag it before anyone would have opened it. The flag is a suggestion, not a verdict, and the human still decides. But it turns “someone should look at every upload” from a rule nobody keeps into a short list of files that need a look. A free image to text tool is the crude version of the same test: if optical character recognition cannot pull the account number off the photo, a reviewer will struggle too.

Which file types should a firm accept from clients?

Accept what clients actually have, and convert on the firm’s side. The alternative, a short allowlist and an error message, sounds tidy and produces the worst outcome in the list: a client who tried, was refused, and stopped.

For documents that exist as downloads, PDF is the answer and nearly every bank, payroll provider, and government portal produces one. For photographs of paper, JPEG and PNG are what Android phones and cameras produce, and HEIC is what iPhones produce by default. An intake that accepts JPEG and PNG but not HEIC is refusing the default format of every recent iPhone, and the refusal lands on the client as “your file is not supported,” which they read as their fault.

There are two honest ways to handle HEIC. The first is to accept it and convert it to JPEG on arrival, which is invisible to the client. The second is to refuse it and tell the client, in the same message, how to switch their camera to Most Compatible. The dishonest way is to refuse it with a generic error and let the client work it out. If the intake takes the second route, the switch instruction has to be in the upload error itself, because a client who is refused will not go looking for a help page.

Beyond images and PDFs, a firm should accept the office formats a client is likely to have on hand: Word and Excel files for a financial schedule a bookkeeper built, a CSV export of transactions, a plain text file. What a firm can refuse without losing anything is video, audio, archives, and executables, none of which is ever the document that was asked for.

Size limits deserve a sentence too. A phone photo is several megabytes and a ten-page scan can be tens. An upload limit set for a form attachment will bounce a real statement, and the bounce is one more place the client gives up.

Where the document is headed sets the floor for all of this. A firm that files with USCIS is bound by the agency’s own definition of a legible copy, published in its tips for filing forms by mail: copies must not be “blurry or faded,” must not be “upside down, lopsided, skewed, or distorted,” and must not have text “obscured, partially cut off, or missing.” A cut-off passport photo fails that standard on its face, and the firm finds out in a Request for Evidence months later. An immigration practice has more reason than most to run the day-one check, because the cost of a bad copy is measured in filing delays rather than in one extra email.

How to reply when the upload is unusable

The reply has one job: get a better copy back within the day, from a client who does not feel told off. Four things make that happen.

Name the item, so the client does not have to guess which of the six things they sent is the problem. Say what was wrong in one plain clause, without adjectives. Say what a good copy looks like, in the same words the original request used. Make it one action.

“Thanks for the pay stubs. The second one is missing the top of the page, so the pay period dates are cut off. Could you retake that one flat on a table with all four corners in frame? The first one is perfect.”

That message names the item, the fault, the fix, and the one that was fine. It takes the client thirty seconds to act on. The version that does not work is “Some of the documents you sent are unreadable, please resend,” which makes the client reopen everything, guess, and often resend the same bad photo.

Send the reply over the channel the client answers. A client who ignored an email will often act on a text the same hour, because the text lands where the phone is, and the phone is where the retake happens. The SMS versus email comparison for document requests covers when each channel wins. For a retake request the answer is nearly always text, because the client can read it, open the camera, and reply without leaving the thread.

Keep the bad copy. It goes in the file as version one, with the retake as version two, so anyone reviewing later can see what was received and when. If the retake is also unusable, the second reply can be more specific still (“the glare is right across the balance, try turning the page so the window is behind you”), and if that fails, the fallback is a different source for the same fact. For a lost or unreadable W-2, the IRS will issue a wage and income transcript from the taxpayer’s online account, which is a download and not a photo. For a bank statement, the bank’s PDF. For a paper ID, a visit to the office with the card, or a video call with the card held up to the camera, depending on what the firm’s own rules allow.

There is a limit to how far a firm should push a single client on a single item. Two retake requests is normal. A third means the request was wrong, not the client, and the fix is to change the instruction or find another source, not to send a fourth message.

When is a phone photo good enough?

More often than firms admit. The instinct to demand a scan comes from a decade ago, when a phone photo really was worse than a flatbed. A modern phone in document mode produces a cropped, flattened, contrast-corrected image that will pass any internal review and most external ones. Refusing it costs the firm a week and a frustrated client, for no gain in what the document proves.

The standard is set by what the document is for. Two cases cover most firms.

For a document the firm reads and files internally, the photo is good enough if the reviewer can read every field the work depends on at full size. That is the whole test. Nobody will ever look at the file again except to confirm what it says.

For a document that goes on to a lender, an insurer, or an agency, the standard is theirs. USCIS publishes its legibility rules, as above. A lender’s underwriting guidelines say what an acceptable bank statement looks like, and a mortgage broker collecting borrower conditions should be checking uploads against those rules on the day they arrive, not on the day the file is submitted. If the rule says “all pages including blank ones,” a photo set that skips the blank fourth page is unusable however sharp the other three are.

The thing to avoid is a single firm-wide rule in either direction. “Scans only” loses clients who have no scanner. “Anything goes” fills the file with photos nobody can read. The workable rule is per item: say for each request what a good copy looks like, accept the photo when it meets that bar, and reply the same day when it does not. A firm that does those three things will find its unusable-upload pile shrinks to the handful of cases where the client really did photograph the wrong page, and those get fixed in one message. The hours that used to go on the rest are the ones the hidden cost of chasing clients for documents adds up, and most of them come back once the file is readable the first time.

Where zendoc fits in document collection

zendoc puts the per-item instruction next to each request in a client’s own list, opened from one link by SMS or email on a phone with no password and no signup form, and accepts PDF, JPEG, PNG, GIF, WebP, HEIC, and the common office formats, converting HEIC to JPEG on arrival so an iPhone photo never bounces. Every upload is read on arrival by AI that classifies the document and flags an unreadable, cut-off, or wrong-type file as a suggestion for staff to review, which moves the day-one check from a rule to a short queue. Each item carries its own state, so the firm sees arrived and usable as different things, and a retake request goes back over the same channel the request went out on. The reviewed files download as PDFs and images for whatever system the firm files them in.