A proposal link that tells a salesperson whether the client has read it

Who the client was and what was getting in the way

We built this system for ourselves first, and we think that is its strongest point. Before recommending a tool to someone, we want to know what it is like to use it every day for several months, not just how it looks in a presentation.

The problem was our own, and very ordinary. We sent proposals as PDF attachments, and from that moment we knew nothing about them. We did not know whether the client had opened the file, read it all, glanced at the first page and closed it, or forwarded it to someone else.

The practical result was that follow-up happened blind. We would write after three days because that seemed appropriate, not because we knew anything about the other person’s engagement. Sometimes we contacted someone who had not even opened the attachment; other times, we left alone someone who had returned to the proposal three times in a week. Both cost us.

Ready-made proposal tools exist, and some track engagement well. We ruled them out for two reasons. First, they charge per user, and for a feature we needed in one place we would have paid every month for the whole team. Second, we wanted a view notification to appear as a note against the right company in HubSpot, not in a separate dashboard someone would have to remember to check. Our own version took one day to build and costs nothing to maintain.

What we built

A proposal is no longer a file; it is a webpage. Each one gets its own random, non-indexed URL. The client clicks a link in an email and reads the proposal in a browser on a phone or computer, without downloading anything.

Tracking runs in the background. We record views, time spent on the proposal, and how far the client scrolls, because the difference between glancing at the introduction and reaching the pricing section is the most useful signal.

The third part is the HubSpot integration. When a proposal is viewed, a note appears on the relevant CRM record showing who viewed it, when, and on which device. This closes the loop: the salesperson gets the information where they already work instead of having to check another tool.

The fourth part covers privacy and expiry. Links are random and non-indexed, so they cannot be found through search or guessed. Proposals have an expiry date; afterward, the page displays an expiration notice instead of the content. This keeps last year’s pricing from circulating.

Technically, the system runs on Next.js 15 with the App Router. Data is stored in Supabase on PostgreSQL with row-level access rules. Vercel provides hosting and the edge layer, and the CRM connection uses version three of the HubSpot API.

How it works today

It took one day to build a working version. The team prepares a proposal as a webpage, generates a link, and emails it instead of attaching a PDF. From then on, the system runs by itself.

The salesperson can see whether the proposal was opened, how long the client spent on it, and how far they got. A note appears in the CRM automatically, giving the follow-up conversation a concrete starting point. After the expiry date, the link no longer displays the proposal.

The outcome

The whole system was built in less than one day. Proposal tracking is fully automatic; no one records anything by hand. Infrastructure costs are zero because everything fits within the free tiers of the services used. View data reaches HubSpot in real time.

What we would do differently

At first, we focused too much on the numbers themselves and not enough on when the salesperson should see them. Time spent on a proposal means little if no one checks a dashboard. The CRM note turned out to be the part that truly changed how we worked, and we should have started there.

The second lesson concerns scroll depth. We measure it, but it can be misleading: a client can scroll through the whole page in ten seconds without reading anything. Next time, we will connect that signal to time spent instead of showing it on its own. Finally, because the tool stores client proposals, rules for expiry and deletion should be agreed at the start rather than added later.