Everything below is fictional. When this gets built for a real operator, the machine log is fed by whatever the service team already uses to track repairs, and the refund decision logic is tuned to that business's own policy, not invented here.
Report a machine problem
Check an existing request
Try MFR-1001, MFR-1002 or MFR-1003 from the sample requests below, or submit a new one on the left.
All requests
Every request is checked against that machine's own log the instant it's submitted: a matching repair record in the last 14 days auto-approves the refund, no match means it waits on a technician to confirm, either way the resident gets a reference number and a stated turnaround instead of silence.
Machine log by building
Log a technician visit
How this gets built for real
The matching rule is a starting point, not policy. "A repair logged in the last 14 days auto-approves" is a simple stand-in; a real build encodes the operator's actual refund policy and can route ambiguous cases to a person instead of auto-deciding.
The machine log needs to be where the service team already works. A real build pulls repair events from whatever ticketing or dispatch tool technicians already use, rather than asking them to type into a second system.
The chronic-machine flag is a starting threshold. Three reports in a rolling window is a reasonable default to surface a problem machine early; a real build would tune that threshold against actual complaint history.
See it built for a real business: SEBCO Laundry Systems.