Most businesses hear about service problems too late: a one-star review, a regular customer who quietly stops coming, or a manager asking why one branch is underperforming with no data to answer. Paper comment cards rarely get filled in, and when they do, nobody tallies them.
A web-based customer satisfaction survey app handles the tedious part: it collects answers in a consistent structure, calculates scores, and shows trends without manual spreadsheets. This guide covers how such a system works, a sensible database design, how to run it on Laravel, and what to check before adopting any ready-made source code.
The Real Problem It Solves
A satisfaction survey is not just "ask for a rating". The goal is to find which touchpoint is weak so you can fix the right thing. Without a system, three issues show up again and again:
- Scattered data. Answers live on paper, in personal online forms, and in chat messages.
- No comparability. Questions and scales change every month, so trends are meaningless.
- Slow reporting. Someone spends hours copying numbers, and the report arrives after the issue is stale.
A good survey system fixes the scale (for example 1 to 5), keeps questions consistent, and computes results automatically, so this month's score can be compared fairly with last month's.
Core Modules and Data Flow
The Laravel survey app discussed here offers 1–5 rating input, multiple questions per survey, automatic tallying, a monitoring dashboard, Excel and PDF export, and respondent management. The flow looks like this:
- An admin defines the questions (staff friendliness, speed, cleanliness, product quality).
- A respondent fills in the form and scores each question from 1 to 5.
- Respondent data and answers are stored in separate tables, one respondent to many answers.
- The system calculates the average per question and an overall score.
- The dashboard shows charts, and the admin exports Excel or PDF reports for meetings.
Recommended Table Design
Whether you buy or build, this structure is a healthy pattern. Keep questions, respondents, and answers separate. Never store all answers in one long text column; it makes filtering and math painful.
| Table | Key columns | Purpose |
|---|---|---|
| questions | id, text, sort_order, is_active | Survey questions |
| respondents | id, name, phone, location, created_at | Who answered |
| answers | id, respondent_id, question_id, score | One score per question |
| users | id, name, email, role | Admins who view reports |
The is_active flag matters: retire old questions instead of deleting them so historical reports stay intact. If you are new to modeling relationships, see designing a simple ERD for your app.
Laravel 11 migration example
Schema::create('answers', function (Blueprint $table) {
$table->id();
$table->foreignId('respondent_id')->constrained()->cascadeOnDelete();
$table->foreignId('question_id')->constrained()->restrictOnDelete();
$table->unsignedTinyInteger('score'); // 1 to 5
$table->timestamps();
$table->unique(['respondent_id', 'question_id']);
});
The unique index stops double submissions when someone taps "send" twice. restrictOnDelete prevents deleting a question that already has answers.
Calculating Scores Correctly
Two numbers are common. The average score per question, and CSAT: the share of answers rated 4 or 5. CSAT is easier to communicate ("78% of customers were satisfied") than an average of 3.9.
$report = DB::table('answers')
->join('questions', 'questions.id', '=', 'answers.question_id')
->whereBetween('answers.created_at', [$from, $to])
->groupBy('questions.id', 'questions.text')
->selectRaw('questions.text,
ROUND(AVG(answers.score), 2) AS avg_score,
ROUND(100 * SUM(answers.score >= 4) / COUNT(*), 1) AS csat_pct,
COUNT(*) AS responses')
->get();
Always show the response count next to the score. A 100% CSAT from three answers means far less than 85% from four hundred. For example, if one store has 12 responses and another has 300, do not rank them on score alone.
Running It Locally
- Install PHP 8.2+, Composer, and MySQL or MariaDB.
- Extract the project and run
composer install. - Copy
.env.exampleto.envand runphp artisan key:generate. - Create an empty database and put its credentials in
.env. - Import the bundled SQL file or run
php artisan migrate --seed, as documented. - Run
php artisan serveand open the URL it prints.
When you are ready to go live, the steps in deploying a Laravel app to shared hosting cover the usual pitfalls.
When and Where to Ask
Even the best system is useless if nobody answers. The best moment to ask is right after the service ends, while the experience is fresh. Practical options:
- A QR code at the counter or waiting area linking to the form. Print one per location with a parameter such as
?unit=store-2so results can be filtered by site. - A link on the receipt or confirmation email after a purchase or appointment.
- A tablet near the exit for clinics, service desks, or schools.
For example, a clinic seeing 40 patients a day where one in five responds would collect roughly 200 answers a month, enough to spot patterns per question. The figure is purely illustrative; real response rates depend on how you ask.
Customizing Safely
- Manage questions in the admin panel, not in code. If they are hardcoded in Blade views, move them into the database.
- Add columns with new migrations. Never edit a migration that already ran in production.
- Use Git from day one so every change can be rolled back.
- Protect the public form. Add the
throttlemiddleware and validate scores.
$data = $request->validate([
'name' => ['required', 'string', 'max:100'],
'scores' => ['required', 'array'],
'scores.*' => ['required', 'integer', 'between:1,5'],
]);
Evaluation Checklist
- A live demo you can click through, not just screenshots.
- Questions can be added, reordered, and deactivated without code changes.
- Answers are stored per question in their own table.
- Excel and PDF exports match the numbers on the dashboard.
- Installation docs state the PHP and Laravel versions.
- The public form has validation and CSRF protection.
- The license says whether client projects are allowed.
Common Mistakes and Fixes
| Mistake | Effect | Fix |
|---|---|---|
| Too many questions | People abandon the form | Keep 5–8 core questions |
| Editing old question text | Trends become incomparable | Create a new question, retire the old one |
| Only watching the average | Pockets of anger stay hidden | Track the count of 1s and 2s |
| No follow-up | Customers feel ignored | Assign an owner to every low score |
Limitations
A 1–5 scale measures well but explains poorly. If you need the "why", add one optional free-text comment. Surveys also only capture people willing to answer; the most frustrated customers often skip them. Treat results as a signal and cross-check them with complaints and repeat purchases. For broader context, read the benefits of business applications for small businesses.
If you want to see a finished implementation, the app is listed on the GudangCode customer satisfaction survey app page.