How Do You Know If Someone Read Your Proposal?
You sent it on Tuesday. It is Friday. There has been no reply, and you are trying to decide between two explanations that could not be more different: they have not looked at it yet, or they have looked at it and are not convinced.
Those two situations call for opposite responses. One wants a nudge; the other wants a phone call and a changed number. Nothing in your inbox tells you which one you are in.
Here is every method people actually use to answer that question, what each one really measures, and where each one quietly lies to you.
Method 1 — Ask
Following up is not a bad method. It is the only one that can produce a reason rather than a signal, and a reason is worth more than any amount of telemetry.
It is just expensive. You get to use it perhaps twice before it stops reading as diligence and starts reading as pressure, and it puts the other person in the position of having to admit they have not got to it.
The real problem with asking is timing. A follow-up sent on the day somebody opened your document reads as attentive. The identical message sent on a day they have not thought about you in a week reads as needy. Asking is a good instrument played at the wrong moment.
Method 2 — The email read receipt
A read receipt is a Message Disposition Notification, specified in RFC 8098. The important word in that specification is disposition: the receipt is generated by the recipient’s mail client, at the recipient’s discretion. Most clients ask first. Many never offer. Corporate mail policy frequently suppresses them outright.
And when one does arrive, look carefully at what it says. It says the email was displayed. Your proposal was an attachment or a link inside that email. A receipt for the envelope is not evidence about the letter.
Method 3 — The tracking pixel in the email
A tracking pixel is a 1×1 image hosted on a server you control and embedded in the message body. When a mail client loads the image, your server logs the request and calls it an open.
That was a defensible proxy for human attention around 2012. It is not one now, and the reason is not that people got better at blocking it — it is that the largest mail clients now fetch remote content on the recipient’s behalf.
- Apple Mail Privacy Protection routes remote content through a proxy and loads it in advance, whether or not the person ever opens the message. Apple describes the behaviour itself in its own documentation.
- Gmail has served remote images through its own caching proxy since 2013, which means the fetch you log may be Google’s, once, on behalf of a message nobody read.
- Corporate security gateways open links and images in inbound mail as a matter of policy, to check them. Those opens look exactly like interested opens.
The failure here is not that the number is noisy. It is that the noise runs in both directions — machines producing opens that did not happen, image blocking hiding opens that did — and nothing in the data tells you which kind any individual row is.
Method 4 — The attached PDF
The moment a PDF leaves your outbox as an attachment it becomes a file on somebody else’s disk. It can be opened on a plane, forwarded to three colleagues, printed, annotated and argued over, and none of that produces a single event anywhere you can see.
This is worth stating plainly because the attachment is still the default way professional work is sent, and it is the only method on this list that generates no signal at all — not a weak one, none — by construction.
What changes when you send a link instead
Send the same document as a link and the thing being measured changes. You are no longer asking whether a mail client fetched an image. You are asking whether a browser loaded the document and stayed on it. That is a much harder event to trigger by accident.
A tracked link can answer, at minimum:
- Whether it was opened at all, and at what time
- How long each visit lasted
- Whether the same reader came back, and how many times
- Whether somebody is reading it right now
- Who it was — when the reader was signed in, or told you
That last one deserves a caveat rather than a bullet, and the caveat is the whole point of doing this honestly. Quixli grades reader identity on three levels rather than one. Somebody signed in to an account is identified. Somebody who typed an address into a gate is self-reported — evidence that they wanted the document enough to hand over an address, and not evidence of who they are, because nobody checked it. Everything else is anonymous. An address you mailed the link to is not treated as an identity at all: links forward, so that address is a fact about your mailing list.
The first open is very often not a person
This is the part nobody warns you about, and it is the one most likely to make you act on nothing.
Paste a link into Slack, Teams, WhatsApp or a modern mail client and the software fetches it immediately, unprompted, to build the little preview card with the title and image. Search crawlers do the same. Security scanners do the same.
If the tool counting your opens does not filter those out, you will be told your client opened your proposal four seconds after you sent it — which is wrong, and is the single most misleading thing an analytics screen can say at the exact moment you are deciding whether to phone somebody.
Quixli identifies automated fetches and keeps them out of every count, every alert and every report. If you are evaluating anything else, ask the same question of it: what happens to the open that fires the instant the link is pasted into a chat?
What a link still cannot tell you
A method you trust too much is worse than one you distrust, so here are the limits, stated before you need them:
- Not where in the document they got to. Quixli records that a document was read and for how long, not which section. There is no scroll map and no per-heading heatmap.
- Not, with certainty, who. See the three grades above. Only a signed-in reader is proof, and most readers of a proposal will never sign in to anything.
- Not exactly where they were. City-level location from an IP address is a hint with a real error rate and a bias that does not average out — here is why.
- Not how many humans. A reader who clears cookies looks like a new person on every visit, so a unique-reader figure is a floor rather than a total. Quixli prints it with a “at least” sign for that reason — what that count really counts.
- Not how long they really read, if the tool is careless about it. A number computed from the time between opening and closing a tab is close to meaningless — this is the honest way to do it.
A protocol for the wait
The point of any of this is to make a decision, so decide the decision first. Write it down before you send, when you are calm and have nothing invested in the outcome.
- Send the document as a link, not an attachment. Everything else on this list depends on it. Attach a PDF as well if the recipient expects one, but make the link the thing you point at.
- Ignore the first hour. Anything in it is more likely to be preview software than a reader, unless it comes with real time on the document behind it.
- Treat a return visit as the real signal. Everybody opens everything once. Almost nobody goes back to a document they have decided against.
- Treat silence after three working days as a message problem. If it has not been opened at all, the proposal is not the thing that failed — the email around it is. Re-send it with a different subject line rather than rewriting the pricing.
- Never quote the telemetry back to them. “I saw you opened it twice on Thursday” is true and unusable. What the signal buys you is timing and framing, not a sentence.
If you want to go further on reading the pattern rather than the single event, what a second opening actually tells you is the next thing to read.
Quixli turns any document into a link that answers these questions. Start free — no credit card.