IMPLEMENTATION CASE STUDY / REALIADAD TECH NOTES
A saved enquiry should mean exactly that.
Inside this site’s interest-capture design: durable storage, explicit consent and safe retries.
The problem: a response is not a record
This website accepts three different requests: academy interest, consultation enquiries and newsletter opt-ins. Each needs a clear purpose and a reliable record. A success message is useful only when the database has accepted the submission.
Put durability before notifications
The capture endpoint validates the request and stores it before reporting success. Optional operator notifications happen afterwards. A notification failure cannot turn a saved enquiry into a lost record, and unavailable storage cannot produce a success confirmation.
Make a retry the same request
The browser attaches a unique submission identifier and retains it if the response is uncertain. Repeating unchanged details uses that same identifier. The database prevents duplicate records; changed details receive a new request identity.
Keep consent separate from a sales enquiry
A consultation does not opt someone into a newsletter. The endpoint checks the request type and selected interest, stores the consent version and timestamp, and records newsletter permission independently. This is a small implementation boundary with a meaningful effect on trust.
Prove the failure cases
The local integration suite exercises duplicate submissions, changed-payload conflicts, rejected input, unavailable storage and rate limits against a temporary database. These checks validate capture behaviour; they do not claim that an email was delivered or a meeting was booked.