A website form becomes operationally useful when the team can see who owns each enquiry, what happened to it and what should happen next. A page-view chart cannot answer those questions. You need business records with explicit states and a small event history.
Here is a focused design for a service business. It covers an enquiry arriving, being assigned, receiving a first response and reaching a terminal outcome. The same design can support bookings or job requests without starting with a large enterprise platform.
1. Define the record and its states
An enquiry record needs an ID, creation timestamp, current status, owner and source. Store contact details separately from analytics identifiers. A useful initial state set is new, assigned, responded, won, lost and closed. Define closed carefully: for example, spam or a duplicate, rather than a sales outcome.
Document allowed transitions. A new enquiry can be assigned; an assigned enquiry can be responded to; a responded enquiry can be won or lost. Corrections and reopened enquiries need explicit transitions too. Do not let an arbitrary dropdown overwrite the state without recording who made the change.
2. Keep a small event history
Use an events table with event_id, enquiry_id, event_type, occurred_at, recorded_at and actor_id. Example events are enquiry_received, owner_assigned, first_response_sent and outcome_recorded. occurred_at is when the action happened; recorded_at is when the system accepted the event. Keeping both helps explain delayed imports.
For a synthetic enquiry E-1042:
09:00 enquiry_received
09:05 owner_assigned
09:20 first_response_sent
14:00 outcome_recorded: won
The first response took 20 minutes from receipt. Assignment took five minutes. These are different measures and deserve different labels.
3. Make retries safe
Website forms and integrations can retry. Require an idempotency key for each submitted enquiry and enforce uniqueness in the database. If the same request arrives again, return the existing record instead of creating another enquiry. Scope the key to the tenant or source so independent customers cannot collide.
Write the enquiry and its receipt event in one transaction. Send notifications after the transaction commits. If reliable asynchronous delivery is needed, save a notification job in the same transaction and let a worker process it. A failed email should not erase a valid enquiry.
4. Define the dashboard numbers
Outstanding enquiries: records that have not reached a terminal state.
Unassigned enquiries: outstanding records with no owner.
First-response time: first_response_sent minus enquiry_received, excluding enquiries without a response from the duration calculation. Show their outstanding count alongside it so a fast average cannot hide unanswered work.
Outcome rate: won divided by won plus lost for a stated cohort. Keep duplicates and spam separate. A receipt-month cohort and an outcome-month report answer different questions; label which one you use.
Source: a business record's captured referral information. Missing source should remain unknown. Do not infer that every enquiry without campaign parameters was direct traffic.
5. Give each role useful access
Staff need their assigned enquiries and contact details. Managers need queue health and team workload. A customer needs only their own submitted request and permitted status information. Enforce access in the server, including tenant isolation; hiding a card in the interface is not an access control.
Avoid putting personal contact details into general telemetry logs. Decide how long enquiry records and their history are retained, and how corrections or removal affect reporting. Analytics totals and business totals can disagree because they measure different things and have different gaps.
6. Verify the edge cases before adding features
Test duplicate form submissions, notification failures, late imported events, reassignment, reopened outcomes and unauthorised cross-tenant reads. Check timestamps around your reporting period boundaries and keep storage in UTC with a clearly labelled display timezone.
Start with one queue and a few honest measures. A dashboard becomes valuable when its numbers match the team's actual work and each record has a clear next step. More charts can follow once those foundations are reliable.
Written for SuperJupiter’s technical publication on custom websites and operational platforms. AI assistance was used in preparing this article. The records and timeline are synthetic examples.
Top comments (0)