NovA double click should not create two property enquiries
A reliable enquiry form should survive repeated clicks, retries and slow feedback without multiplying one buyer action into duplicate conversations.
This article reflects the named expert’s practical perspective. See NovAsia’s editorial policy for how material is prepared and reviewed.
A duplicate property enquiry is easy to dismiss as a minor interface annoyance. It becomes less minor when two records reach different people, two replies are sent, and the buyer is suddenly asked the same question twice. A single uncertain click has turned into two parallel histories.
That outcome tells me something important about the product. The system has treated the number of technical submissions as though it were the number of user intentions. Those are not always the same thing.
The buyer acts once even when the network sends more than once
Imagine a buyer submitting a question about one apartment. The button appears unresponsive, so they click again. Or the connection stalls after the form leaves the browser and the buyer retries. In both cases the person still intends one thing: send this enquiry.
The platform should preserve that meaning. It does not matter whether the internal implementation uses a request token, a submission identifier, a queue or another approach. The public requirement is clearer than the engineering detail: repeating the same attempt should not create a second independent enquiry simply because the first result was not visible quickly enough.
At the same time, similarity is not enough to define a duplicate. A buyer may contact the same project again later with a different question. They may correct a phone number, add a document, or ask about another unit in the same development. If the system collapses every similar message, it can lose legitimate follow-up actions.
The distinction is therefore between a repeated attempt to complete one action and a new action that happens to look similar.
The easiest duplicate to handle is the one the interface never invites. After the first click, the form should make it obvious that something has happened. The buyer should be able to distinguish at least three outcomes: the submission is in progress, it has been accepted, or it has failed without a confirmed result.
A silent button is dangerous because it encourages experimentation. Click again. Refresh. Return to the page. Try the form a second time. Each of those actions is rational if the interface has offered no trustworthy feedback.
Disabling the button for a moment can help, but it is not a complete solution. The state needs to reflect the real process, not merely a short animation in the browser. If the user interface resets while the backend is still processing the first attempt, it effectively invites a duplicate.
The confirmation message matters for the same reason. “Sent” should mean the product has reached the stage it is actually willing to treat as successful. A cheerful success state that appears before the system can confirm acceptance is just another form of uncertainty, only with better typography.
A retry after failure should be safe
The hardest moment is partial failure. The buyer clicks, the request reaches part of the system, but the response never makes it back to the browser. From the buyer’s side there is no reliable answer. They should not be expected to know whether the enquiry exists.
A robust flow makes the natural retry safe. If the original submission was already accepted, the repeated attempt should not create a second conversation. If the original genuinely failed, the retry should complete the action. That behaviour removes a lot of pressure from the interface because the product no longer needs perfect connectivity to preserve one intention.
An honest “we could not confirm the result” state is better than claiming success without evidence. But that honesty only helps if the next attempt does not make the situation worse.
Duplicate handling also needs to cover side effects. One stored enquiry can trigger several internal notifications without becoming several enquiries. Conversely, one email sent to a manager does not prove that the database contains only one record. The unit of truth should remain the buyer’s action and the conversation attached to it.
Once a team starts measuring duplicate reduction, it is tempting to remove anything that looks repetitive. That creates the opposite failure: a real second enquiry disappears.
Time, context and what changed between attempts matter. Two identical payloads a fraction of a second apart are very different from two similar messages on different days. A repeated question after a price update may be entirely intentional. A buyer who adds a new condition should not be silenced because their name and phone number match the previous record.
The system should not be judged only by how few duplicates remain. Valid follow-ups also need to survive. Reliability means avoiding both multiplication and accidental deletion.
A useful audit looks at the final conversation history. Can the team see one coherent thread for one action? Can later genuine actions be distinguished? Did the buyer receive one appropriate confirmation rather than several automated responses competing with each other?
The best form lets the buyer forget about this problem
The successful experience is uneventful. The buyer clicks once, sees that the action is being processed, receives one confirmation and continues with the property decision. If the connection fails, a retry does not produce chaos. If the buyer later sends something genuinely new, it is preserved as new.
That is why I see duplicate submissions as more than a button bug. They test whether the product understands user intent across an imperfect network. Property conversations carry context over days or weeks. Splitting one first contact into two records can damage that context before the actual discussion has even begun.
A form is reliable when the user does not need to manage its uncertainty manually. One intended enquiry should become one coherent enquiry, regardless of how many times the transport layer had to try.