Let visitors report broken pages with a screenshot and the page URL

Turn reports into an owned maintenance workflow

The field table below groups page context separately from the report itself. Reviewers first see where the visitor encountered the issue. They can then use the feedback type to decide whether the report belongs with content, design, support, or engineering.

Keep the feedback type options aligned with the queues your team actually uses. A vague catch-all category produces reports that require another classification step. A small set of familiar categories lets a reviewer route a report quickly while preserving the reporter's original wording.

Treat the page URL as evidence, not as a guaranteed reproduction path. The visitor may be signed in, using a locale, or carrying query parameters that change the result. Compare the URL with the account and request context your application already records before you decide that a page defect exists.

The screenshot is a static file, not a live DOM snapshot. It shows what the reporter chose to include, not console errors or a way to reproduce the bug. Ask for browser details through a follow-up process when a visual report needs more technical investigation.

Do not make the form carry every diagnostic question. A visitor can report a broken page in seconds when the request stays focused. Your internal review can request a screen recording, device details, or reproduction steps after triage identifies a report worth investigating.

Adapt the template for a mobile app

For a mobile app, replace page_url with a screen_name select that matches your app's own navigation. A URL often has no useful meaning to someone using a native screen. A screen name lets the reporter identify the place they saw without translating your navigation into a web address.

Use labels that visitors recognise from the app. Match tab names, menu labels, and screen titles. Keep historic option values understandable when navigation changes, because past reports still need to tell a reviewer where the original issue appeared.

The feedback_type and screenshot fields still serve the same purpose in an app variant. The type directs the report to the right reviewer. The screenshot gives that reviewer the visible state, even when the current release has already changed.

Avoid treating the screenshot as a substitute for version information. A screenshot can show the UI, but it cannot identify a release build or device behaviour by itself. Connect the form to the application context you already collect if a report needs that level of diagnosis.

Route submissions in your Laravel application

FilaForms emits FormSubmitted after a visitor submits website feedback. Listen for FilaForms\Core\Events\FormSubmitted and read page_url, feedback_type, and screenshot from the submission data. The listener can record the report in your logs before you replace that action with your own triage workflow.

Save this listener as app/Listeners/LogWebsiteFeedback.php. Laravel 12 discovers listeners in app/Listeners automatically.

<?php

namespace App\Listeners;

use FilaForms\Core\Events\FormSubmitted;
use Illuminate\Support\Facades\Log;

final class LogWebsiteFeedback
{
    public function handle(FormSubmitted $event): void
    {
        $data = $event->submission->data;

        $pageUrl = $data['page_url'] ?? null;
        $feedbackType = $data['feedback_type'] ?? null;
        $screenshot = $data['screenshot'] ?? null;

        Log::info('Website feedback received', [
            'form_id' => $event->form->getKey(),
            'submission_id' => $event->submission->getKey(),
            'page_url' => $pageUrl,
            'feedback_type' => $feedbackType,
            'screenshot' => $screenshot,
        ]);
    }
}

Route different feedback types to the people who can act on them. A content report may need an editor. A page failure may need an engineer. Keep the original submission available when a reviewer creates a ticket, because the screenshot and page URL explain why the work started.

Set a review cadence before publishing the form. A fast acknowledgement can help support reports. A weekly review may suit small visual issues. The best destination depends on whether your team fixes pages through a support queue, a content workflow, or an engineering backlog.

Use the FilaForms features for Laravel and Filament to decide where notifications, conditional fields, and submission analytics fit your maintenance process. The template supplies the reporting structure. Your application supplies ownership, response time, and the work that resolves the report.

When this template is the wrong tool

Choose a different reporting approach when your team needs technical telemetry from the visitor's browser. This template records what the visitor submits. It does not collect console errors, network failures, session replay, or an automatic reproduction path.

It is also the wrong tool when the report must prove that an issue affects every visitor. A single submission identifies an experience worth checking. Your team still needs monitoring, tests, and direct investigation to establish scope and cause.

Use this form for direct reports that need page context and a visible record. Use your own diagnostic tools when you need browser-level evidence or automated error collection. That division keeps the visitor form short and keeps technical investigation with the systems built to support it.