Case file 007Feedback
The problem
“We get feedback, but it falls through the cracks. Staff never sees the angry customers.”
Solved
- For
- Agencies and their local business clients
- Built
- Feedlyn: survey form, incident tracker, mobile app, reviews manager
- Stack
- Express · React · MongoDB · Expo mobile app
- Result
- Live at feedlyn.intezamtech.com
01 · The pain
Good feedback stays. Bad feedback vanishes.
Feedback arrives without any system to route it. High ratings feel good. Low ones? They disappear into email and are never acted on.
Perfect service
Really good
Cold food
Will come back
Rude staff
Amazing
Slow service
Good value
Forgotten order
Loved it
Scroll to watch: high ratings stay. Low ratings fade and fall away. Without a system, angry customers are forgotten.
02 · The fix
Rate it. We route it.
A working model of Feedlyn’s feedback intake. Submit sample ratings as a customer and watch the system route low ones into incidents that staff must handle.
Will create an incident
Submissions
0
Avg rating
—
Incidents
0
Resolved
0
Incidents (staff sees these)
No incidents yet. Submit a low rating to create one.
All submissions feed
Submit feedback to see it here.
03 · How it works
Three steps, and a threshold that never lets angry customers disappear.
A public survey form for customers
Each business gets a shareable survey link. Customers rate their experience and answer follow-up questions without creating an account.
Ratings that demand attention
When a rating comes in, the system sees its value. If it's 3 or below, an incident is created automatically and sent to the staff app.
Staff follow it to resolution
Incidents get a code, a status timeline, and a comment thread. Staff can assign, update status, and the mobile app sends push alerts.
The hard part
One rating value makes all the difference.
A customer fills the survey. The system reads their rating and makes a split-second decision: is it 3 or below? If yes, an incident is created with its own code and the staff are notified. Ratings of 4 and 5 stay as submissions and never become incidents.
Each code is readable at a glance: three letters of the business name, the date, and that day’s running number. The database refuses a duplicate code, so two incidents can never be confused on a busy day.
Customer submits
rating: 2
channel: in_store
issueCategory: serviceSystem checks threshold
2 <= 3?
yes → create incidentStaff sees
code: INT-261013-0001
status: created
assigned to: [staff name]04 · What changed
Negative feedback became something staff could not ignore.
- Incidents tracked monthly
- —
- Resolution time
- —
- Businesses on platform
- —
Metric to confirm · low ratings that became actionable items
Metric to confirm · from creation to marked resolved
Metric to confirm · tenants with active staff