Sharing a Document With Your Team Without Losing Track of Who Sent What
The first time it happens it is almost funny. A client mentions the proposal and two people on your side say "yes, I sent that" — and both are right, from two accounts, with two links, and neither can see the other’s numbers.
The second time it happens somebody follows up on a document that a colleague already followed up on that morning. That is the version that costs you something.
This is a bookkeeping problem dressed as a tooling problem, and it has a clean solution as soon as you decide two things: what a link means, and who is allowed to see what it produced.
Rule one: a link means a recipient, not a document
The habit worth building before anything else is one link per recipient. Not one link per document that everyone reuses — one link created for the person it is going to.
It costs nothing and it buys the thing every other question in this article depends on: when a visit appears, you know which chain it arrived through. A shared link that three colleagues pasted into three conversations produces a merged pile of visits that no amount of analysis will separate afterwards.
It is also what makes forwarding legible instead of invisible — what a forwarded link can and cannot tell you goes through why a per-recipient link is the single highest-value habit in this whole category.
Rule two: decide who can see whose numbers, deliberately
This is the setting people discover by accident, usually at the worst moment. It is worth setting it on purpose in the first week.
A Quixli team workspace has two states for analytics visibility, and the default is the narrow one:
- Own only (the default). Each member sees the read data for documents and links they own. Nobody else’s numbers appear in their dashboard.
- Workspace-wide. Every member sees every member’s. Useful for a small team where the pipeline is genuinely shared, and unnecessary friction for one where it is not.
Two properties of that switch deserve stating rather than discovering. Turning it on is retroactive — it exposes what already happened, not only what happens next — and every member of the workspace is notified when it changes. That notification exists because a silent widening of who can see your activity is the kind of change people are entitled to know about.
And here is the part that is not flattering and is true anyway: the workspace owner and its admins always see everything, whatever the setting says. That is not configurable. If you are a member of a team workspace, the people who administer it can see the read data for the documents you sent. Better that you learn it here than infer it later.
Rule three: documents stay private until a share exists
A common and reasonable fear about moving into a shared workspace is that everything you write becomes everybody’s. It does not.
Inside a Quixli team workspace, your documents are yours. A colleague — including an owner or an admin — cannot open a document you wrote simply by virtue of being in the same workspace. The only route from one member’s document to another member’s screen is a share that was deliberately created.
Note the asymmetry, because it is deliberate and it surprises people: content is private to its author, while read data is governed by the visibility setting above and is always visible to admins. Documents and the numbers about them are treated as two different kinds of thing.
Rule four: your own team’s opens are not client opens
The failure mode here is quiet and it corrupts everything downstream. A colleague proofreads the proposal through the client’s link, and now the client appears to have read it twice before the email even went out.
Opens by the document’s owner and by active members of the workspace that owns it are recognised and kept out of the client-facing counts, notifications and averages. So is the fetch that fires when a link is pasted into a chat channel and a preview card is built. Both matter for the same reason: an open that is not a reader is worse than no data, because it arrives at exactly the moment you are deciding whether to phone somebody.
A working arrangement for a small team
- One link per external recipient, always, created by the person who owns the relationship. Everything else depends on this.
- Pick your analytics visibility in week one and tell everyone which it is. Including the part about admins.
- Share internally with the team, not by forwarding the client’s link. A document shared with the workspace lands in each member’s "shared with me" and keeps their reading out of the client’s numbers. Forwarding the client link is the direct cause of the previous section’s problem.
- Agree who follows up before you send. The read signal is a prompt to act, and two people acting on the same prompt is the most avoidable embarrassment in this whole territory.
- Make ownership an offboarding step. When somebody leaves, their links do not stop existing. What actually happens to them is worth knowing in advance — what happens to a shared link when the person who sent it leaves is the next article, and it is the one people read too late.
A team workspace is a paid arrangement billed per active member, and the plans set out what comes with it. If you are one person, none of this applies yet and a personal workspace does the same job for one — but rule one applies to you today, and it is the one that cannot be retrofitted.