Web Lead System
User & Installation Guide

1. Server requirements

Confirm compatibility before uploading the system. Your exact release may specify a newer minimum version.

• A valid SSL certificate and forced HTTPS
• Access to the hosting file manager, SFTP, or a deployment tool
• Access to database creation and scheduled backups
• A working mail service or authenticated SMTP provider
• A private administrative email address for the primary owner

2. Installation: beginning to end

These steps describe a conventional self-hosted installation. Keep the supplied filenames and directory relationships intact.

Recommended file structure

1. Back up the existing website

   Download the current website files and export its database. Record the PHP version and active DNS/mail settings.

2. Create the application database

   In the hosting control panel, create a dedicated database and database user. Generate a unique password and grant that user access only to this database.

   Import the supplied schema file using the hosting database tool. Do not reuse a WordPress administrator password.

3. Upload the application package

   Extract the release ZIP locally. Upload the complete application folder to /public_html/web-lead-system/ using SFTP or the hosting file manager.

4. Protect private directories

   Prevent direct web access to configuration, storage, backups, and logs. Apply the server rules supplied with the release and confirm that opening a protected file URL returns 403 Forbidden.

5. Enter the server configuration

   Set the database host, database name, username, password, application URL, organization name, timezone, mail transport, sender address, and reply address in the supplied configuration file or setup screen.

6. Set production mode

   Disable visible PHP errors, enable secure session cookies, set the application environment to production, and confirm HTTPS is forced before login credentials are created.

7. Connect the website form

   Point the public contact form to its installed receiver, normally /api/contact/contact.php. Match every HTML field name and allowed option to the server configuration.

   Use a honeypot, same-origin validation, rate limiting, and server-side validation. Never rely on browser validation alone.

8. Test delivery without real customer data

   Submit a clearly labeled test lead. Confirm it appears once in the dashboard, reaches the intended notification mailbox, and sends a visitor confirmation only when that option is enabled.

9. Create the primary owner

   Open the private application URL and complete first-run setup. The first authorized account becomes the Primary Owner. Use a unique password and record the recovery method securely.

10. Add the initial team

    Invite users into available seats, assign job titles, and grant only the permissions each person needs. Confirm each invitation individually.

11. Complete the launch checklist

    Test login, logout, password recovery, lead reply, internal message, transfer approval, export, archive, mobile layout, and backup restoration before announcing the system to employees.

3. Users, roles & permissions

Titles describe people; permissions control actions. “Carpenter,” “Estimator,” or “Office Coordinator” can be customized without granting unrestricted authority.

4. Reading the dashboard

The dashboard concentrates the work that needs attention. What appears depends on the logged-in user’s permissions.

5. Managing leads

A lead should move through a deliberate lifecycle. Avoid leaving an inquiry unassigned or using archive as a substitute for answering it.

Daily lead workflow

1. Open the lead and verify the contact information.
2. Review screening indicators and previous activity.
3. Assign the lead to the appropriate authorized user.
4. Reply from the lead thread so the response remains recorded.
5. Set a status and schedule the next action.
6. Close or archive only when the outcome is understood.

6. Internal messages

Messages let authorized users coordinate without exposing private notes to the website visitor.

7. Assignment & transfer requests

Users may request a reassignment, but sensitive transfers should remain subject to owner or delegated approval.

1. Request

   The current assignee selects the proposed recipient and provides a business reason.

2. Review

   The authorized decision-maker reviews workload, experience, history, and fairness.

3. Approve or deny

   The system records the decision, decision-maker, time, and reason.

4. Notify

   Affected users receive the outcome. The lead remains with the original assignee until approval succeeds.

8. Company announcements

Announcements distribute organization-wide information and can request acknowledgement.

• Use a clear title, publication time, expiration date, and priority
• Request acknowledgement only when confirmation is genuinely needed
• Review recipient and acknowledgement counts from the sender’s view
• Use approved decorative images sparingly and provide accessible alternative text
• Allow expired announcements to leave the active dashboard while preserving the record

9. User accounts

Add a user

1. Open Team and select an available seat.
2. Enter the person’s real name, company email, title, and access profile.
3. Review permissions; remove anything unnecessary.
4. Send the invitation. The seat remains pending until accepted.
5. Confirm the user can log in and sees only the intended information.

Edit, suspend, or deactivate

Title and permissions may change as responsibilities change. Suspension temporarily blocks access. Deactivation permanently ends access without destroying historical records.

Temporary delegation

The Primary Owner may grant selected capabilities to an authorized user for a fixed period. Delegation should expire automatically and must not transfer ownership, billing control, or historical ownership records.

10. Appearance & branding

Owner-only controls can coordinate the application with the business website without exposing arbitrary CSS or font changes.

11. Records, reports & exports

The system preserves operational history; it does not prove a person’s physical location or identity at a specific moment.

12. Security checklist

• Force HTTPS and secure session cookies
• Use unique passwords and multi-factor authentication when supported
• Hash passwords with PHP’s current password API; never store plain text
• Use prepared database statements and server-side authorization on every action
• Require CSRF tokens for state-changing requests
• Validate, limit, and encode all visitor input
• Disable file uploads unless a separately secured feature explicitly requires them
• Keep configuration, logs, exports, and backups outside public reach
• Rate-limit login and form submissions
• Review active accounts and delegated authority regularly
• Apply supported PHP, database, application, and server updates
• Maintain off-server encrypted backups and test restoration

13. Maintenance schedule

Safe update procedure

1. Read the release notes and confirm server compatibility.
2. Back up files and database.
3. Test the update in a staging copy with fictional data.
4. Place production in maintenance mode if required.
5. Upload only the documented changed files and run migrations once.
6. Clear server/browser caches and complete the regression checklist.
7. Roll back immediately if records, permissions, or mail behavior are inconsistent.

14. Troubleshooting

15. Support information

Before requesting assistance, record what happened, the exact time, the signed-in role, browser, page address, and visible error. Remove passwords and customer-sensitive data from screenshots.

End of Web Lead System Documentation.