carmanagement/docs/car_booking_no_customer_account_fix_plan.md

Plan: Fix and Simplify Car Booking Without Adding Customer Accounts

Objective

Improve the car booking process while keeping the current guest booking model.

This plan does not add:

• Customer accounts
• Customer login
• Renter dashboard
• Global customer profile
• Cross-company customer sharing
• Saved customer identity

The goal is to make booking smoother, safer, and simpler while keeping each company’s customer data private.

---

Current Direction

The system should continue using this structure:

Company
  └── Customer
        └── Reservation

A customer who books with Company A exists as a customer under Company A.

If the same person books with Company B, they become a separate customer under Company B.

This is the correct approach for now.

---

Core Privacy Rule

Customer data must always belong to one company.

The system must never allow Company A to view, edit, search, or infer customer data from Company B.

Correct model:

Company A
  └── john@example.com

Company B
  └── john@example.com

These are two separate customer records.

Do not create a shared global customer record.

---

Phase 1: Keep Guest Booking Only

Decision

Do not build customer accounts now.

Booking should work without login.

The customer only submits the information needed to request a booking.

Required Behavior

When a customer books a car:

1. Customer selects a car.
2. Customer enters basic booking and contact information.
3. Backend finds the car.
4. Backend derives the company from the car.
5. Backend finds or creates a customer under that company.
6. Backend creates a reservation under that company.

The customer should not need to create an account to make a booking.

---

Phase 2: Simplify the Booking Form

Problem

The current booking process asks for too much information too early.

That creates friction and makes the booking feel heavier than it needs to be.

Fix

The first booking form should only ask for:

• Name
• Email
• Phone
• Pickup date
• Return date
• Pickup location
• Return location
• Optional message

Move These Fields Out of the First Step

Do not require these during the initial booking request:

• Driver license
• License expiration date
• Government ID
• Passport
• Full address
• Document upload
• Payment details

These can be requested later during verification or approval.

New Booking Flow

Step 1: Request Booking
  - Customer contact info
  - Trip dates
  - Pickup and return locations
  - Notes

Step 2: Company Reviews Request
  - Company checks availability
  - Company accepts, rejects, or asks for more details

Step 3: Verification If Needed
  - License
  - Address
  - Documents
  - Payment

This keeps the first action lightweight.

---

Phase 3: Derive Company Ownership From the Car

Problem

The frontend should not decide which company owns a reservation.

If the frontend sends companyId, it can be wrong, manipulated, or stale.

Fix

The backend must derive companyId from the selected car.

Correct backend logic:

const car = await prisma.car.findUnique({
  where: { id: input.carId },
  select: {
    id: true,
    companyId: true,
  },
});

if (!car) {
  throw new Error("Car not found");
}

const companyId = car.companyId;

Then use that companyId for both the customer and reservation.

The frontend may send carId, but the backend decides the company.

---

Phase 4: Find or Create Customer by Company and Email

Required Rule

Customers should be unique inside each company, not globally.

Use:

@@unique([companyId, email])

This allows:

john@example.com under Company A
john@example.com under Company B

without mixing their records.

Booking Logic

const normalizedEmail = input.email.toLowerCase().trim();

const customer = await prisma.customer.upsert({
  where: {
    companyId_email: {
      companyId,
      email: normalizedEmail,
    },
  },
  update: {
    name: input.name,
    phone: input.phone,
  },
  create: {
    companyId,
    email: normalizedEmail,
    name: input.name,
    phone: input.phone,
  },
});

Important

Do not use email alone to find a customer.

Bad:

where: {
  email: input.email
}

Good:

where: {
  companyId_email: {
    companyId,
    email: normalizedEmail
  }
}

---

Phase 5: Create Reservation With Company Scope

Every reservation must be linked to:

• companyId
• customerId
• carId

Recommended reservation creation:

const reservation = await prisma.reservation.create({
  data: {
    companyId,
    customerId: customer.id,
    carId: car.id,
    startDate: input.startDate,
    endDate: input.endDate,
    pickupLocation: input.pickupLocation,
    returnLocation: input.returnLocation,
    notes: input.notes,
    status: "PENDING",
  },
});

Initial reservation status should be:

PENDING

The company can later change it to:

APPROVED
REJECTED
CANCELLED
COMPLETED

---

Phase 6: Enforce Company Privacy in Dashboard Queries

Problem

If company dashboard routes fetch customer or reservation records only by ID, one company may accidentally access another company’s data.

That is a serious multi-tenant privacy bug.

Fix

Every company-facing query must include companyId.

Bad:

await prisma.customer.findUnique({
  where: { id: customerId },
});

Good:

await prisma.customer.findFirst({
  where: {
    id: customerId,
    companyId: currentCompany.id,
  },
});

Bad:

await prisma.reservation.findUnique({
  where: { id: reservationId },
});

Good:

await prisma.reservation.findFirst({
  where: {
    id: reservationId,
    companyId: currentCompany.id,
  },
});

Apply This Rule To

• Customers
• Reservations
• Cars
• Documents
• Notes
• Payments
• Messages
• Invoices
• Reviews

Anything owned by a company must be queried with company scope.

---

Phase 7: Prevent Cross-Company Search

Company staff should never be able to search all customers globally.

Company customer search must always filter by the company.

Correct:

await prisma.customer.findMany({
  where: {
    companyId: currentCompany.id,
    OR: [
      { name: { contains: search, mode: "insensitive" } },
      { email: { contains: search, mode: "insensitive" } },
      { phone: { contains: search, mode: "insensitive" } },
    ],
  },
});

Incorrect:

await prisma.customer.findMany({
  where: {
    email: { contains: search },
  },
});

The second version searches across companies and should not exist.

---

Phase 8: Improve Booking Status Feedback

After submission, show a clear confirmation page.

The customer should see:

• Booking reference
• Car name
• Pickup date
• Return date
• Status: Pending
• Company name
• Message: The company will review your request.

Do not leave the customer wondering whether the booking worked.

Optional Confirmation Email

Send a confirmation email with:

• Booking reference
• Car details
• Dates
• Company name
• Status
• Support or contact information

No customer account required.

---

Phase 9: Add Booking Reference

Add a public-safe booking reference to reservations.

Example:

BK-2026-8F3K2

This is useful for emails, support, and later booking lookup.

Recommended field:

bookingReference String @unique

The reference should not expose database IDs.

Bad reference:

cm8x9customeridreservationid

Good reference:

BK-7H92KQ

---

Phase 10: Optional Booking Lookup Without Account

If needed later, allow customers to check booking status without creating an account.

Use:

booking reference + email

Example:

Booking Reference: BK-7H92KQ
Email: john@example.com

The backend should only return limited information:

• Status
• Car name
• Company name
• Pickup date
• Return date
• Pickup location
• Return location

Do not expose:

• Internal notes
• Admin comments
• Risk flags
• Documents
• Payment metadata
• Other bookings
• Other company records

This gives convenience without building full accounts.

---

Phase 11: Add Validation

Validate booking input on both frontend and backend.

Required Validations

• Email must be valid.
• Phone must be valid enough for contact.
• Start date must be before end date.
• Start date cannot be in the past.
• Car must exist.
• Car must be active/listed.
• Car must belong to an active company.

Date Validation

Reject:

• Return date before pickup date.
• Same-day invalid ranges if not allowed.
• Past pickup dates.

Availability Validation

Before creating a reservation, check whether the car already has an overlapping approved or pending reservation.

Example logic:

const overlappingReservation = await prisma.reservation.findFirst({
  where: {
    carId: car.id,
    status: {
      in: ["PENDING", "APPROVED"],
    },
    startDate: {
      lt: input.endDate,
    },
    endDate: {
      gt: input.startDate,
    },
  },
});

if (overlappingReservation) {
  throw new Error("Car is not available for the selected dates");
}

This avoids double booking.

---

Phase 12: Add Tests

Add tests for the booking flow and company privacy.

Test 1: Booking creates company-scoped customer

Given:

Company A
Car A belongs to Company A
Customer books Car A

Expected:

Customer is created under Company A
Reservation is created under Company A

Test 2: Same email can book with two companies

Given:

john@example.com books with Company A
john@example.com books with Company B

Expected:

Two customer records exist
One under Company A
One under Company B

Test 3: Company cannot view another company’s customer

Given:

Customer belongs to Company B
Company A user tries to fetch that customer

Expected:

404 or 403

Test 4: Company cannot view another company’s reservation

Given:

Reservation belongs to Company B
Company A user tries to fetch it

Expected:

404 or 403

Test 5: Backend ignores frontend companyId

Given:

Frontend sends carId for Company A
Frontend also sends companyId for Company B

Expected:

Reservation is created under Company A

The backend must trust the car ownership, not the frontend payload.

Test 6: Double booking is blocked

Given:

Car has an approved reservation from June 10 to June 15
Customer tries to book June 12 to June 14

Expected:

Booking is rejected

---

Phase 13: Implementation Order

1. Audit current booking form.
2. Classify fields as required now, optional now, move to verification, or remove.
3. Simplify the frontend booking form.
4. Update booking API to accept carId and derive companyId from the car.
5. Normalize email before lookup or storage.
6. Find or create customer using companyId + email.
7. Create reservation with companyId + customerId + carId.
8. Set initial reservation status to PENDING.
9. Audit company dashboard routes.
10. Add companyId filtering to every company-owned query.
11. Prevent cross-company customer and reservation search.
12. Add reservation availability check.
13. Add booking confirmation page.
14. Add confirmation email if email infrastructure exists.
15. Add booking reference if not already present.
16. Add tests for booking creation, company isolation, and double-booking prevention.
17. Deploy carefully.
18. Run migration only if schema changes are needed.

---

What Not To Change Now

Do not add:

• Renter model usage
• Customer login
• Customer password
• Customer dashboard
• Shared profile
• Cross-company booking history
• Saved documents
• Saved payment methods

Do not change customer uniqueness to global email.

Do not let companies search customers outside their own company.

Do not trust companyId from the frontend.

---

Acceptance Criteria

This work is complete when:

• A customer can book without creating an account.
• The booking form is shorter and easier to complete.
• Customers are created per company using companyId + email.
• The same email can exist under multiple companies.
• Reservations are always tied to the correct company.
• The backend derives companyId from carId.
• Company dashboards cannot access another company’s customers.
• Company dashboards cannot access another company’s reservations.
• Overlapping bookings are blocked.
• Booking confirmation is clear.
• Sensitive information is not collected too early.

---

Final Recommendation

Keep the system guest-based for now.

Fix the booking process by simplifying the form, enforcing company-scoped data access, deriving company ownership from the car, and preventing double bookings.

This gives the product a cleaner booking process without adding customer accounts before they are actually needed.