A document link that still works a week later
Cancellation requests arrive in a staff chat with the customer's signed paperwork attached — except the link was usually dead by the time anyone clicked it. I replaced it with one that never expires and still can't be guessed.
When a customer asks to cancel a policy, the request lands in an internal Telegram group: which product, which policy, how much money is coming back, and the signed application the customer uploaded.
It was a good notification with one flaw. The link to that document was normally dead by the time anybody clicked it.
A message the team opens days later
Uploaded files live in cloud storage, and cloud storage hands out links that expire after about fifteen minutes. That's a sensible default for a page someone is looking at right now. It's useless for a chat message, because staff don't work that way:
- A request that arrives at six in the evening gets opened the next morning.
- A disputed one gets reopened a week later, when somebody asks what the customer actually signed.
- The group is a running record, so old messages get scrolled back to on purpose.
The notification had a shelf life of a quarter of an hour, after which it became a screenshot of a problem rather than a way to solve one.
A link anyone can open, that nobody can guess
The link now points at our own system rather than the storage provider, and never expires. Which raises the obvious question: with no login involved, what stops anyone who gets hold of the address from reading a stranger's cancellation papers?
Every link carries a short signature, calculated from the request number and a secret key that exists only on the server. That gives three properties:
- Only we can make a valid link. Without the key the signature can't be produced, so an address can't be constructed or guessed from outside.
- Editing the address doesn't help. Change the request number and the signature stops matching, and the request is refused.
- Every failure looks identical. A wrong signature, a request that doesn't exist and a request with no document all answer the same "not found" — otherwise the different replies would themselves reveal which requests are real.
One small change had an outsized effect on the staff side: the file is renamed on the way out. A customer's own "scan.pdf" tells nobody anything and collides with every other one in the downloads folder. It now arrives named after the request number.
Tapping instead of selecting
The other half of the job was the message itself. Most of this team works from a phone, and the first thing they do with a cancellation request is copy the policy number into another system.
On a phone, selecting a long number out of a paragraph is genuinely irritating — you get a word, or the whole line, rarely the thing you wanted. So the numbers are tappable now: the key values copy themselves when touched, and there are buttons beneath the message that put the policy number or the request number straight onto the clipboard. Pressing them posts nothing back into the group.
There's a deliberate safety net behind that. Older Telegram versions don't understand copy buttons and reject the entire message rather than quietly dropping them — which would mean the team never hears about the cancellation at all. So a message that gets refused is immediately re-sent without the buttons. A convenience should never cost you the notification.
Why I'm proud of it
It's a small feature — a link and two buttons — but it's the kind that quietly decides whether an internal tool gets used or worked around. A dead link never gets reported as a bug. People just start phoning each other instead, and you never find out.
The other thing I made certain of is that none of it can reach a customer. The notification runs on its own timeout with its own error handling, so if Telegram is slow or the group is misconfigured, the cancellation still goes through and the failure lands in our logs rather than in the customer's way.