Trucking TMS Core Pages and Navigation

Context / Goals

AttuneLogic's current trucking experience already includes many of the building blocks of a trucking TMS, especially in the web app. The main opportunity is not to start over, but to make the trucking information architecture clearer and more intentional so users can move through the full load lifecycle more naturally.

This proposal aims to:

• Define the core trucking TMS pages AttuneLogic should treat as first-class.
• Compare the current implementation to that target model.
• Recommend a phased, backwards-compatible rollout path.
• Clarify which pages belong on web vs mobile.

Non-goals for this proposal:

• Rewriting the current job/load architecture.
• Introducing breaking API contract changes.
• Solving every future trucking feature in one release.

Principles

• Backwards compatible: existing trucking customers should keep using current flows while naming, navigation, and feature boundaries improve.
• Load lifecycle first: the page model should map cleanly to quote/load intake, dispatch, delivery, documents, payout, and invoicing.
• Role-aware: dispatchers, admins, accounting, and drivers do not need the same navigation or depth.
• Web is system-of-record; mobile is operational companion: the web app should carry the heavier TMS surface area, while mobile should stay focused on driver and field workflows unless a strong mobile ops need emerges.
• Incremental rollout: prefer relabeling, regrouping, and strengthening current pages before adding entirely new feature areas.

Current State Summary

Web (@attunelogic-service)

The current trucking-facing web navigation already covers much of a practical TMS:

• Dashboard
• Jobs
• Dispatch
• Invoices
• Manifests
• Payouts
• Clients
• Drivers
• Reports
• Settings

There is also Equipment in routes, plus rate and dispatch-related settings. In practice, this means the product already supports much of the operational trucking flow, but some capabilities are either:

• named in a way that is more generic than trucking users expect,
• split across multiple sections,
• present as secondary pages instead of first-class trucking destinations.

Mobile (@attunelogic-mobile)

The mobile app is currently much narrower and appears aligned to an operational companion experience:

• Home
• Loads
• Messages
• More

This is appropriate for driver-focused trucking usage, but it does not represent a full trucking TMS on mobile today.

Current Coverage vs Target Trucking TMS

Area	Typical Trucking TMS Expectation	Current State	Assessment
Dashboard	Daily operational overview	Dashboard exists	Strong
Loads / Orders	Main load system of record	Jobs effectively fills this role	Strong, but naming gap
Dispatch Board	Assignment and schedule management	Dispatch exists	Strong
Customers / Brokers / Shippers	Customer account management	Clients exists	Strong, but trucking naming may need refinement
Drivers	Driver records and assignment	Drivers exists	Strong
Trucks / Trailers	Dedicated fleet asset management	Equipment exists, but not clearly split for trucking	Partial
Documents / Load Packets	BOL, POD, confirmations, packet visibility	Spread across Jobs, Manifests, detail views	Partial
Manifests / Trip Sheets	Driver/load packet and trip grouping	Manifests exists	Strong
Invoicing	Customer billing	Invoices exists	Strong
Driver Pay / Settlements	Driver compensation and payout workflows	Payouts exists	Strong
Reports	Ops and financial reporting	Reports exists	Strong
Rates	Load pricing and defaults	Exists under Settings > Rates	Partial
Maintenance	Equipment maintenance tracking	Present in equipment area, not first-class	Partial
Tracking / Visibility	Load status, ETAs, route visibility, exceptions	Embedded in dispatch/load flows, not clearly first-class	Partial
Compliance / Safety	CDL, insurance, permits, inspections, safety docs	Not clearly exposed as a trucking domain	Missing / future
Alerts / Exceptions	Late loads, expiring docs, failed check-ins	Not clearly first-class	Missing / future

Proposed Core Trucking Page Model

The recommended first-class trucking page model for AttuneLogic is:

1. Dashboard
2. Loads
3. Dispatch
4. Customers
5. Drivers
6. Fleet
7. Manifests
8. Documents
9. Invoices
10. Payouts
11. Reports
12. Settings

Recommended Meaning of Each Page

1) Dashboard

Operational summary for dispatch, accounting, and management:

• active loads
• unassigned loads
• in-transit loads
• delivered not invoiced
• overdue invoices
• driver/fleet exceptions

2) Loads

This should be the primary trucking system-of-record page.

Recommended position:

• Treat existing Jobs as the trucking Loads page in user-facing terminology.
• Preserve underlying data model compatibility where Job remains the backend container if needed.

This page should represent:

• load intake
• load details
• legs/stops
• statuses
• driver assignment visibility
• rates and charges
• attached documents

3) Dispatch

The operational assignment board for:

• assigning drivers
• reviewing upcoming work
• spotting unassigned work
• updating schedule-related status

This is already a core strength and should remain first-class.

4) Customers

Use this page for:

• shippers
• brokers
• direct customers
• related locations and account settings

Recommended position:

• Existing Clients can remain the underlying model/UI implementation initially.
• Trucking-facing copy should favor Customers where that improves clarity.

5) Drivers

The main people-management page for trucking operations:

• driver profiles
• assignment context
• payout visibility
• reports/history

6) Fleet

This should become the clearer trucking-facing home for vehicles and trailers.

Recommended position:

• Existing Equipment should evolve into a trucking-facing Fleet concept.
• Within fleet, distinguish at minimum:
  • trucks / power units
  • trailers
  • optionally other equipment later

7) Manifests

Keep this as a first-class trucking page for:

• load packets
• grouped trip execution artifacts
• printable driver-facing paperwork
• settlement support

8) Documents

This should become a more explicit cross-load document view over time.

Examples:

• rate confirmations
• bill of lading
• proof of delivery
• signed paperwork
• uploaded images/files

Short-term, this can remain distributed across load and manifest pages. Longer term, a dedicated documents page or filtered document center would improve discoverability.

9) Invoices

Customer billing after delivery/completion.

10) Payouts

Driver or contractor compensation.

11) Reports

Operations and financial reporting for trucking.

12) Settings

Tenant-level configuration for:

• rates
• dispatch settings
• templates
• users
• reports config
• notifications

Must-Have Pages for the Trucking MVP

If AttuneLogic wants a clean trucking-focused MVP definition, the must-have pages are:

1. Dashboard
2. Loads
3. Dispatch
4. Customers
5. Drivers
6. Fleet
7. Manifests
8. Invoices
9. Payouts
10. Reports

Near-Must-Haves Right After MVP

• Documents
• Rates
• Maintenance
• Alerts / Exceptions

Proposal for Current-to-Future Mapping

Rather than introducing many new domains at once, AttuneLogic should map current pages into a clearer trucking model.

Current Page	Proposed Trucking Position	Recommended Action
Dashboard	Dashboard	Keep and strengthen trucking KPIs
Jobs	Loads	Relabel in trucking-facing UX first; keep backend compatibility
Dispatch	Dispatch	Keep first-class
Clients	Customers	Consider trucking-facing rename or dual terminology
Drivers	Drivers	Keep first-class
Equipment	Fleet	Reframe and split into trucks / trailers over time
Manifests	Manifests	Keep first-class
load/manifests attachments	Documents	Start as federated views, then evaluate standalone page
Invoices	Invoices	Keep first-class
Payouts	Payouts	Keep first-class
Reports	Reports	Keep first-class
Settings > Rates	Rates capability	Keep under settings initially

Web vs Mobile Proposal

Web

The web app should continue as the full trucking operations surface.

Recommended primary trucking nav on web:

• Dashboard
• Loads
• Dispatch
• Customers
• Drivers
• Fleet
• Manifests
• Invoices
• Payouts
• Reports
• Settings

Mobile

The mobile app should stay focused on operational execution rather than becoming a full admin TMS immediately.

Recommended trucking mobile structure:

• Home
• Loads
• Messages
• More

Potential future additions only if validated by user need:

• Documents
• Inspections
• Fuel / Expenses
• Driver Earnings

Data Model / API Impact

This proposal can begin with minimal contract changes.

Short-term

• Keep Job as the underlying load container if needed.
• Keep Client as the underlying customer entity if needed.
• Keep Equipment as the underlying asset entity if needed.
• Change user-facing terminology, nav labels, grouping, and docs first.

Medium-term

Possible domain clarifications without breaking existing contracts:

• add explicit fleet subtypes for truck vs trailer
• add more formal document categorization
• add explicit trucking exception types
• add clearer load lifecycle reporting fields where needed

Avoid in early phases

• full model renames that break API consumers
• broad route renames without compatibility aliases
• forcing mobile to mirror web admin complexity

Rollout Plan

Phase 1: Clarify Navigation and Terminology

• Define trucking-facing labels:
  • Jobs -> Loads
  • Clients -> Customers where appropriate
  • Equipment -> Fleet in trucking contexts
• Update docs and internal product language to consistently describe the trucking flow.
• Keep underlying models and API contracts unchanged.

Phase 2: Strengthen Partial Areas

• Improve Fleet structure for trucks vs trailers.
• Improve cross-load document discoverability.
• Promote maintenance and rate configuration where operationally needed.
• Add stronger dashboard and report slices around trucking operations.

Phase 3: Add Operational Gaps

• Introduce first-class Alerts / Exceptions.
• Evaluate Tracking / Visibility as either a dedicated page or a stronger dispatch/load experience.
• Evaluate Compliance / Safety only when operational scope justifies it.

Migration / Backwards Compatibility Strategy

• Preserve current route contracts initially, even if labels change in the UI.
• Use tenant-config or app-type-aware labeling to avoid disrupting non-trucking experiences.
• Prefer additive page framing and navigation regrouping over destructive rewrites.
• Roll out per customer or feature flag where needed if navigation shifts are substantial.

Open Questions

• Should trucking customers see Loads everywhere user-facing while internal engineering keeps Job terminology?
• Should Customers remain a single shared concept across industries, or should trucking explicitly introduce Brokers / Shippers views later?
• Should Documents become its own page, or remain primarily embedded within Loads and Manifests?
• When does Fleet need truck/trailer separation strongly enough to justify dedicated pages instead of filtered tabs?
• Should Tracking live as a dedicated nav item, or remain inside Dispatch and Loads until live telematics maturity increases?

Recommendation

AttuneLogic should treat the current trucking web product as a strong base for a trucking TMS, not as a greenfield redesign. The most important next move is to align the product around a clearer trucking page model:

• Jobs should function as Loads
• Clients should function more clearly as Customers
• Equipment should evolve into Fleet
• Documents, Tracking, and Maintenance should be strengthened as supporting trucking capabilities

This approach gives AttuneLogic a more recognizable trucking TMS shape without breaking the current customer workflows that already exist today.