Non-technical documentation

Dashboard

Dispatchly is the freight brokerage CRM. A load starts as a lead, becomes a priced quote, becomes an order after the brokerage accepts it, gets a carrier, moves on the road as a dispatch, and then Accounts bills the customer and records payment.

This page is for staff, project managers, and QA. It explains what people do, who can see what, and what goes wrong. It is not a developer contract.

Pipeline

flowchart LR
  Lead --> Quote
  Quote --> Approval
  Approval --> Order
  Order --> Carrier
  Carrier --> Dispatch
  Dispatch --> Delivered
  Delivered --> Invoice
  Invoice --> Payment

Who uses it

Everyone who can sign in lands on a dashboard. What they see depends on role. Sales people see their pipeline. Dispatchers see loads on the road. Admins see the brokerage as a whole. Analytics charts on the dashboard also differ by role.

Who works which stage

Typical workflow

1. A lead arrives (manual entry, marketing import, or website capture).
2. Sales qualifies it, adds a vehicle or other freight item, and converts it to a quote.
3. Sales prices the quote, emails the customer, and can send an eDocs sign link from that quote.
4. Someone creates an order from the quote. Admin or Sub Admin skip extra approval and land in awaiting dispatch. Everyone else goes pending approval.
5. Admin, Sub Admin, or Dispatch Head approve. Then a carrier is assigned, which creates the dispatch and moves the order toward client signature.
6. Dispatch runs the load. Delivered or cancel closes related dispatches and syncs the order.
7. Accounts send the invoice (this is what marks invoice sent) and record money in.

What you can and cannot see

• Sales usually see their own assigned leads, quotes, and sales-owned orders. Sales Head sees the sales team.
• Dispatchers usually see loads assigned to them. Dispatch Head sees all dispatches.
• Accounts see orders waiting for client signature / billing, not the whole sales pipeline.
• Admin and Sub Admin see everything their access allows.
• Converted leads leave the active lead list (they are quoted / inactive). Converted quotes leave the active quote list when an order is created.

If two people disagree about “missing” records, check assignment and role first. The CRM hides rows the person is not allowed to see. Search and sidebar badges follow the same rule.

Related screens

• Leads, Quotes, Orders, Dispatch, Accounts — the pipeline.
• Analytics — role-specific charts, not a second pipeline.
• Notifications and Calendar — follow-ups and reminders.
• Public Lead Capture — website form setup (Tenant ID and allowed origins).
• Docs hub Health — API up/down only.
• Swagger UI — developer contract.

Common mistakes

• Expecting every role to see every load. They will not.
• Looking for website leads only on the capture hub. Capture creates CRM leads; staff work them in Leads.
• Treating Health or Swagger as staff training. They are ops and developer tools.
• Confusing platform Admin (subscription and Owner templates) with Accounts billing of customers.

Auth

Auth is how staff get into the CRM and stay signed in. People use email and a password. The CRM keeps the session alive with a short-lived sign-in and a refresh so they do not retype the password all day.

Who uses it

Every staff member. New hires also use the invite accept page (see Users). Customers do not use this login — they use eDocs or a public profile link.

Typical workflow

1. Open the CRM login screen. Enter email and password. The app encodes the password before it is sent; staff still type a normal password.
2. Stay signed in while working. When the short session expires, the CRM refreshes in the background.
3. Forgot password: request a reset. An email OTP is sent. Enter the code and a new password.
4. Verify email: a separate OTP flow from password reset. Use it when the account still needs email confirmation.
5. Change password while logged in from Profile. The current password must be confirmed first.
6. Sign out when done on a shared machine.

flowchart LR
  Login --> Session
  Session --> Refresh
  Forgot --> EmailOTP
  EmailOTP --> NewPassword
  Profile --> ChangePassword

What you can and cannot see

• You see your own Profile: name, email, password change, and (for Admin / Sub Admin) Tenant ID.
• You cannot see other people’s passwords. Encoded passwords from the app are not something staff copy around.
• A suspended user cannot sign in even with the right password.
• An expired invite cannot be used to create a login. Admins resend or issue a new invite.

Related screens

• Users — invites, activate, suspend, delete.
• Settings — company timezone and (Admin) IP allowlist that can block sign-in from unknown networks.
• Public profiles — a shareable page, not a login.
• Desktop app — download only while already logged in.

Common mistakes

• Mixing up password reset OTP with email verification OTP. They are separate emails and separate screens.
• QA posting a raw password into a tool that expects the encoded form the CRM app sends. Staff UI is fine; API tests are not this page.
• Assuming Tenant ID is on every Profile. Only Admin and Sub Admin see it.
• Leaving a browser signed in on a shared desk. Refresh keeps the session alive until logout.
• Blaming “broken login” when the IP allowlist (Admin) is blocking the office or VPN.

SSE

SSE (live updates) keeps lists, sidebar badges, and notifications current without a full page refresh. When someone else converts a lead or marks a notification read, your screen can update while you stay on it.

Who uses it

Everyone signed in. Sales notice new website leads. Dispatchers see assignment changes. Accounts see invoice and payment updates. Nobody “turns SSE on.”

Typical workflow

1. Sign in. The CRM opens a live connection in the background.
2. Work as usual. New rows, badge counts, and bell items arrive without refresh.
3. If the laptop sleeps or the network blips, wait a moment. The connection comes back. If it does not, refresh once.

What you can and cannot see

• You only receive updates for records and notifications you are allowed to see.
• You cannot see another person’s private list magically appear. Live updates still respect role and assignment.
• You do not see a technical event log. That is Request logs (Admin / Sub Admin).

Related screens

• Notifications — bell items arrive over the same live channel.
• Nav counts — sidebar badges drop or rise as lists change.
• Leads / Quotes / Orders / Dispatch — tables stay in sync across staff.

Common mistakes

• Refreshing constantly “to be safe.” You usually do not need to.
• Reporting a bug because two people see different lists. That is visibility, not a failed live update.
• Asking IT to “enable SSE” in Settings. It is not a tenant setting.

Users

User Management is the staff directory: who can sign in, which department and role they have, whether they are active, and (for sales and dispatch roles) commission.

Who uses it

• Admin — create, invite, activate, suspend, and delete users.
• Sub Admin — create, invite, activate, and suspend. Cannot delete users.
• Heads — see people in their department. Sales Head / Dispatch Head who are team heads can manage team members (see Teams).
• Everyone else — typically do not browse the full staff table. Sales cannot browse Admin accounts there.

Typical workflow

1. Admin or Sub Admin invites a person. The email includes a link that expires in 7 days.
2. The invitee sets a password and joins. Status becomes active.
3. If the link expires, resend the invite or cancel and send a new one.
4. Activate or suspend when someone starts, leaves, or should lose access immediately.
5. Only Admin deletes a user record. Prefer suspend if you may need the history later.
6. For Sales, Sales Head, Dispatch, and Dispatch Head, set commission (percentage or a fixed amount) if the brokerage pays it.

What you can and cannot see

• You never see your own row in the table.
• Heads see their department, not the whole company unless they are Admin / Sub Admin.
• Lower roles do not browse higher-role accounts (Sales does not list Admins).
• Commission belongs on sales and dispatch roles. Do not expect it on Accounts or Marketing.

Related screens

• Departments, Roles, Permissions — what the person can click after they join.
• Teams — grouping with a head and members; website origins for inbound leads.
• Auth / Profile — password, photo, Tenant ID, public profile URL.
• Analytics — commission charts for sales and dispatch roles.

Common mistakes

• Deleting instead of suspending. Only Admin can delete; history and assignment get harder to explain.
• Letting a 7-day invite expire and assuming the person “cannot log in because the CRM is down.”
• Assigning loads to a suspended user. They will not work them, and others may not see the row the way you expect.
• Looking for yourself in User Management to upload a photo. Use Profile.

Departments

Departments are the brokerage org buckets: Sales, Dispatch, Accounts, Marketing, and Admin-style groups. People, teams, and email templates hang off department. Admin configures them.

Who uses it

Admin and Sub Admin add or retire departments. Heads live in a department and see their people. Staff do not pick a department on every lead — the user’s department comes from their user record.

Typical workflow

1. Admin creates departments that match how the brokerage actually works.
2. Each user is placed in a department when invited or created.
3. Teams can optionally sit in a department.
4. Retire a department only after people have been moved. Empty names confuse reporting.

What you can and cannot see

• Staff see their own department on Profile and in Analytics filters that apply to them.
• They do not get a company-wide department editor unless they are Admin / Sub Admin.

Related screens

• Users — department on each person.
• Teams — optional department on a working group.
• Roles and Permissions — what that department’s jobs can do.
• Email templates — heads create templates for their department’s work.
• Analytics — dashboards differ by role and department focus.

Common mistakes

• Creating look-alike departments (“Sales” and “Sales Team”) so heads cannot find their people.
• Expecting a department change to move historical leads by itself. Assignment and team routing still matter.

Teams

A team is a working group with a head and members. Use teams when several salespeople or dispatchers should share inbound work, and when a website should dump leads to a specific group.

Who uses it

• Admin and Sub Admin create teams, name them, set a head, and attach website origins.
• Sales Head or Dispatch Head who are the head of that team can manage members.
• Members receive work routed to the team (especially website leads).

Typical workflow

1. Admin / Sub Admin create the team and choose a head.
2. Add members. The head can keep membership current if they are a Sales Head or Dispatch Head for that team.
3. For inbound web leads, attach the site origin on the team (or on Settings if it should not belong to one team).
4. Copy Tenant ID from Profile (Admin / Sub Admin) and finish setup on Public Lead Capture.
5. When a lead arrives from that origin, staff work it in Leads like any other lead.

flowchart LR
  Website --> OriginCheck
  OriginCheck --> Team
  OriginCheck --> TenantSettings
  Team --> Lead
  TenantSettings --> Lead

What you can and cannot see

• Heads see their team’s people and can manage members when they are the team head (Sales Head / Dispatch Head).
• Creating the team itself is Admin / Sub Admin — heads do not spin up new teams on their own.
• A salesperson still usually sees their own assigned pipeline unless they are Sales Head.

Related screens

• Users — who can be a head or member.
• Settings — tenant-wide website origins (Origin tab).
• Leads — where routed website inquiries land.
• Public Lead Capture — how to copy Tenant ID and test the form.

Common mistakes

• Website origin not allowlisted on Settings or the team. Capture is blocked; no lead appears.
• Same origin on Settings and a team, then wondering why Team A got the lead. Team wins.
• Trying to send assignee, stage, or team in the public form body. Origin routing decides the team. Do not train the website to pick a salesperson that way.
• Asking a Sales Head to “create a new team” when they can only manage members of a team they already head.

Roles

A role is a named job in the brokerage. Built-in roles cover the desks people actually sit at. Admin can also create custom roles. The role decides the default permission set and, with department, what lists and dashboards look like.

Who uses it

Admin and Sub Admin assign roles when inviting or editing a user. Staff do not pick their own role.

Built-in roles

Typical workflow

1. Decide the desk before inviting. One person can have more than one role if the brokerage truly needs that.
2. Admin / Sub Admin attach the role on the user.
3. If the job is unusual, create a custom role and attach permissions instead of overloading Admin.

What you can and cannot see

• Staff see their role on Profile. They do not see other people’s permission matrices unless they administer roles.
• Analytics, sidebar badges, and search all shrink to the role.

Related screens

• Permissions — the fine switches behind the role.
• Users — where the role is attached.
• Analytics — sales vs dispatch vs admin dashboards.

Common mistakes

• Giving Sales “a bit of dispatch” by making them Admin. Use permissions or a custom role.
• Expecting Dispatch to edit quote vehicles. They cannot.
• Confusing Admin (platform + CRM) with Accounts (customer invoices).

Permissions

Permissions are the fine switches behind each role: who can read a list, assign a salesperson, assign a carrier, send an invoice, and so on. Changing a role’s permissions changes what those staff can click the next time they work.

Who uses it

Admin and Sub Admin. Staff never “turn on a permission” for themselves. QA should treat missing buttons as a permission or role issue before logging a product bug.

Typical workflow

1. Start from a built-in role that matches the desk.
2. If someone needs one extra action (for example assign sales on a lead), adjust that role or make a custom role.
3. Have the person sign out and back in if a new permission does not appear yet.
4. Spot-check: can they see the list, open a record, and complete the action?

What you can and cannot see

• Staff see or do not see buttons. They do not see machine permission names in the CRM the way developers do.
• Assigning a lead or quote to a salesperson requires assign access, not only “edit the lead.”
• Assigning a carrier on an order requires carrier-assign access. Without it, the happy path stops even if the order is approved.

Related screens

• Roles — the bundle permissions hang on.
• Users — who has which role.
• Leads / Quotes / Orders — assign and convert actions.
• Accounts — send invoice and payment updates.

Common mistakes

• Logging “Convert is broken” when the user cannot create an order or cannot assign sales.
• Copying Admin permissions onto a salesperson “just for this week.”
• Forgetting that list visibility and action visibility are different. Seeing a quote is not the same as converting it.

Admin

Admin here means the platform control slice inside the tenant: subscription, feature flags, and paperwork templates synced from the Dispatchly Owner platform. It is not the Accounts desk that bills shippers.

Brokerage invoices for your customers live under Accounts, Invoices, and Payments. The bill you pay Dispatchly for using the CRM is the platform subscription. Do not mix the two in training or QA.

Who uses it

Tenant Admin and Sub Admin. Owner-side operators publish plans and templates. Tenant admins look at the plan and apply template updates when Owner publishes them.

Typical workflow

1. Owner assigns a plan and features. The tenant receives them automatically. Nobody in the brokerage “invents” a feature flag.
2. When Owner publishes a new paperwork template version, a tenant Admin applies the update (see Templates).
3. If a module is missing for everyone, check whether the plan includes it before changing CRM permissions.

What you can and cannot see

• Admins see plan / feature status and template diffs when Owner has published something new.
• Sales and dispatch do not administer the subscription.
• Platform commercial history is a mirror of Owner. It is not the customer invoice list.

Related screens

• Templates — Owner paperwork packets, not Email templates.
• Settings — company name, timezone, origins, integrations.
• Accounts — customer billing workbench.
• Activity logs / Request logs — Admin / Sub Admin troubleshooting.

Common mistakes

• Training Accounts to “look at Admin for unpaid invoices.” Wrong bill.
• Assuming a feature is a CRM bug when the Owner plan never enabled it.
• Editing Email templates and thinking Owner paperwork templates changed. Different modules.

Leads

A lead is a new freight inquiry: someone wants a vehicle or other freight moved. Sales list it, qualify it, assign it, and convert it to a quote when it is ready to price.

Who uses it

• Sales — own assigned leads.
• Sales Head — the sales team’s leads.
• Marketing — imports and campaigns can create leads; staff then work them here.
• Admin / Sub Admin — full access they are granted.

Typical workflow

1. Create a lead (or receive one from the website / marketing import).
2. Add origin / destination, contact, and at least one vehicle or other item.
3. Assign to a salesperson if you have assign access. Without it, assignment is refused.
4. Move stage as you work: New → Contacted → Quoted, or Lost if it dies. Stages also include Order, Dispatch, Delivered, and Closed as the deal progresses downstream.
5. When contact name and transport type exist, convert to a quote. The lead becomes inactive (quoted) and leaves the active list.
6. Use internal notes and history for the next person. Keep the customer address accurate — convert copies the saved customer address onto the quote.

flowchart LR
  Inquiry --> Lead
  Lead --> Assign
  Assign --> Qualify
  Qualify --> Quote
  Qualify --> Lost

Stages staff use

What you can and cannot see

• Sales usually see assigned leads only. Sales Head sees the team. Admin / Sub Admin see what they can access.
• After convert, the lead is inactive. Look for the quote (and later the order) instead of hunting an “open” lead.
• Website leads look like any other lead. There is no separate “web only” inbox in Leads.
• You can add vehicles, other items, internal notes, and read history on the lead.

Related screens

• Quotes — where convert lands.
• Customers — created from the contact when email is present; update address before convert if it is wrong.
• Marketing — campaigns and imports that create leads.
• Bulk operations — reassign many leads; convert many leads to quotes (max 100).
• Public Lead Capture — origin allowlist and Tenant ID.

Common mistakes

• Converting without contact name or transport type. Convert fails.
• Converting a lead that is already quoted. You get “already converted,” not a second quote.
• No vehicle and no other item. The inquiry is incomplete.
• Website origin not allowlisted. Capture is blocked; sales never see a lead.
• Assigning without assign access. The save looks like it should work and then refuses.
• Editing the quote address after convert instead of fixing the customer first next time — convert copies the customer’s saved address.

Quotes

A quote is the priced offer and the paperwork packet for a deal. Sales set tariff and terms, email the customer, use the Aqua pricing helper, and send an eDocs sign link from this quote. You turn a quote into an order by creating an order off the quote — not a separate mystery “Convert” button in the API sense. In the CRM, that is the create-order-from-quote action (including bulk with a preview).

Who uses it

• Sales — own quotes.
• Sales Head — team quotes.
• Admin / Sub Admin — full access they are granted.
• Dispatch may read what they need for the load, but they do not edit the quote package.

Typical workflow

1. Open the quote created from the lead (or created directly if that is how your office works).
2. Confirm vehicles / other items, lane, and customer email.
3. Price it. Use Aqua / AI pricing as a hint from origin, destination, and history — not as a final tariff.
4. Set a sales status (New, Hot, Warm, Cold, On Hold, Archived, and the other campaign / color labels the board offers).
5. Approval on the quote can be draft, pending, approved, or rejected depending on how the office submits it.
6. Email the customer from the quote. Send the eDocs sign link from eDocs using this quote when paperwork should be signed.
7. Create an order from the quote when they are ready to book. The quote becomes inactive. You cannot convert it again.

Statuses and approval

What you can and cannot see

• Sales see assigned quotes. Converted quotes drop off the active list when an order exists.
• You see pricing, customer email, vehicles, others, notes, and history.
• You do not get a second convert after an order was created. Bulk convert will list that quote as already converted.
• Missing customer email blocks later order convert and eDocs / invoice email. Fix it on the quote or customer before you book.

Related screens

• Leads — source of most quotes.
• Orders — created from the quote.
• eDocs — customer signs; staff send the link from the quote.
• AI pricing / Aqua helper — suggested price.
• Email templates — optional bodies when emailing.
• Bulk operations — preview then convert many quotes to orders (max 100).

Common mistakes

• Quote already converted. Creating another order from it fails. Open the existing order.
• Missing customer email. Convert to order and eDocs both fail.
• Tariff left at 0. You may still create a bad price; Accounts cannot invoice a zero tariff later.
• Asking dispatch to add a vehicle on the quote. They are blocked.
• Sending a sign link before the quote is the one you mean. eDocs is bound to that quote.
• Confusing quote approval with order approval. Creating the order has its own pending / approved path.

Orders

An order is the booked load after the quote. It carries pricing, customer, vehicles / other items, assignment, approval, carrier, nested notes, signatures, calendar events, payments on the order, and a BOL view. Dispatch and Accounts both live off this record as it moves.

Who uses it

• Sales — still see sales-owned orders they are allowed to see; they can update operational fields they have access to.
• Dispatch / Dispatch Head — board, carrier, movement.
• Admin / Sub Admin — create with skip-ahead approval, approve / reject, full access they are granted.
• Accounts — once the order is awaiting client signature (after carrier assign).

Typical workflow

1. Create the order from the quote. Admin or Sub Admin skip extra approval and land in awaiting dispatch. Everyone else goes pending approval.
2. Admin, Sub Admin, or Dispatch Head approve (order becomes awaiting dispatch) or reject (order gone, quote rejected).
3. Assign a carrier (needs carrier-assign access). That creates the dispatch and moves the order toward client signature.
4. Work nested records: vehicles, other items, notes, calendar events, signatures, payments on the order, BOL view.
5. Send invoice from the order emails the customer — it does not mark invoice sent. Accounts send-invoice does that.
6. Delivered or cancel on the order closes related dispatches.

flowchart TD
  Quote --> CreateOrder
  CreateOrder --> PendingApproval
  CreateOrder --> AwaitingDispatch
  PendingApproval --> Approve
  PendingApproval --> Reject
  Reject --> QuoteRejected
  Approve --> AwaitingDispatch
  AwaitingDispatch --> AssignCarrier
  AssignCarrier --> ClientSignature
  ClientSignature --> Accounts

Statuses

What you can and cannot see

• Sales usually see sales-owned orders. Dispatchers see assigned loads. Dispatch Head sees dispatch-side broadly. Accounts see awaiting client signature, not every draft.
• Nested on the order: vehicles, others, BOL view, calendar events, notes, signatures, payments on the order.
• You cannot assign a carrier on a pending-approval order. Bulk assign fails the whole selection if any selected order is not approved.
• Order “send invoice” is an email. It is not the Accounts flag that says invoice sent.

Related screens

• Quotes — source; reject returns here as rejected.
• Dispatch — created when a carrier is assigned.
• Carriers — who you assign.
• Accounts — billing workbench after client-signature status.
• Invoices / Payments modules — brokerage invoice records, different from Accounts payment status on the order.
• Calendar — events can also live on the order.
• Bulk — reassign; preview then assign carriers (approved only).

Common mistakes

• Order not approved, then carrier assign fails. Approve first.
• Reject “to send it back” without realizing the order is deleted.
• Missing customer email — later invoice and some emails fail.
• Tariff 0 — Accounts cannot send invoice.
• Expecting order send-invoice to show Invoice sent on Accounts. It will not. Use Accounts send-invoice.
• Creating a second order from a converted quote. Already converted.

Dispatch

Dispatch is the load on the road. The record is created when a carrier is assigned on an approved order. Status moves from unposted through posted, confirmed, dispatched, picked up, in transit, delivered, or cancelled. BOL upload lives here. Delivered or cancel syncs the related order.

Who uses it

• Dispatch — loads assigned to them.
• Dispatch Head — all dispatches.
• Admin / Sub Admin — full access they are granted.
• Accounts read combined order + dispatch on the billing workbench; they do not run the board.

Typical workflow

1. After carrier assign, the dispatch appears on the board (often unposted).
2. Post and confirm with the carrier, then mark dispatched when it is actually sent.
3. Upload BOL here (field paperwork). Do not stash POD on the original quote packet.
4. Picked up → in transit → delivered. Delivered syncs the order.
5. Cancel if the load dies. That also syncs / closes with the order side.

What you can and cannot see

• Dispatchers usually see assigned loads only. Dispatch Head sees all.
• You see carrier, dates, vehicles, BOL, notes, and status.
• You cannot edit quote vehicles from dispatch. Wrong equipment is a sales/quote problem.
• You cannot email the customer from dispatch after delivered.

Related screens

• Orders — parent load; carrier assign creates this record.
• Carriers — drivers, insurance, trailers.
• Accounts — after awaiting client signature.
• Files vs BOL — BOL belongs on dispatch; the Files library is separate.
• Bulk — reassign many dispatches (max 100).

Common mistakes

• Marking delivered, then trying to email the customer from dispatch. Blocked.
• Uploading BOL on the quote because “that is where the packet was.” Wrong place.
• Cancelling dispatch and expecting the order to stay happily open without checking order status.
• Looking for a dispatch before a carrier was assigned. It does not exist yet.

Carriers

The carrier book is the companies you cover loads with. Name is required. Nested records cover drivers, insurance, trailers, extra contacts, and attachments.

Who uses it

Dispatch and Dispatch Head day to day. Admin / Sub Admin maintain the book. Sales may see names when a load is covered but do not run carrier compliance.

Typical workflow

1. Create the carrier with at least a name. Add MC / contact details as your office requires them in the form.
2. Add drivers, insurance certificates, trailers, extra contacts, and attachments.
3. On an approved order, assign this carrier (needs carrier-assign access). That creates the dispatch.
4. To change cover, assign a different carrier on the order (reassignment updates the existing dispatch rather than pretending the first assign never happened).

What you can and cannot see

• Dispatchers see the book they are allowed to use and the carriers on their loads.
• You cannot assign a carrier to an unapproved order.
• A carrier without a name cannot be saved.

Related screens

• Orders — assign carrier.
• Dispatch — the live load after assign.
• Bulk — assign carriers to many approved orders (preview first; each order needs a carrier chosen).

Common mistakes

• Assigning before approval. Fails.
• Bulk selecting a mix of approved and pending orders. The assign is refused until the pending ones are out of the set.
• Creating duplicate carrier companies because search was not used first.

Customers

Customers are shipper / payer records created from contacts on leads, quotes, and orders (find-or-create by email when an email exists). Sales can also create a customer by hand. You assign a sales owner. There is no delete.

Who uses it

• Sales can create and work customers on their pipeline.
• Sales Head / Admin / Sub Admin update more broadly.
• Dispatchers see customers on their loads, not the whole sales book.

Typical workflow

1. Enter a lead or quote with name plus email and/or phone. A customer row is created or linked.
2. Or create a customer manually (name, and at least email or phone).
3. Assign a sales owner so the right closer sees them.
4. Deactivate if they should not appear as active. You still cannot delete.

What you can and cannot see

• Sales see customers on their pipeline. Dispatchers see customers on their loads.
• Open a customer to see linked leads, quotes, and orders they are allowed to see.
• No delete. Duplicate emails conflict; do not create a second Jane with the same email.

Related screens

• Leads / Quotes / Orders — where contacts become customers.
• Accounts — bills this customer’s email. Missing email blocks send invoice.
• eDocs — signing still needs a usable customer email on the quote.

Common mistakes

• Trying to delete a customer. Not offered. Use inactive.
• Missing email, then failing convert, eDocs, or invoice later.
• Dispatchers expecting the full customer directory. They see load customers.
• Fixing an address only on the quote after convert instead of on the customer for the next load.

Invoices

Invoices in this module are brokerage invoice records tied to orders — the formal invoice objects in the CRM. They are not the platform subscription bill, and they are not identical to the Accounts screen’s payment status on the order.

Who uses it

Accounts, Accounts Head, Admin, Sub Admin. Sales and dispatch do not live here for day-to-day billing.

Typical workflow

1. An order exists with a real tariff and customer email.
2. Accounts (or an invoice action you are allowed to use) creates / sends against that order.
3. Payments in the Payments module attach to these invoice records.
4. Separately, Accounts still tracks pending / invoice sent / partial / paid on the order workbench.

What you can and cannot see

• You see invoice records for orders you are allowed to bill.
• You do not see Dispatchly’s bill to the brokerage (that is Admin / Owner subscription).
• A zero tariff cannot be invoiced. Missing customer email cannot be emailed.

Related screens

• Accounts — workbench for awaiting client signature; send invoice marks invoice sent.
• Payments — money against invoice records.
• Orders — send invoice emails the customer but does not mark invoice sent.
• Admin — platform subscription, different bill.

Common mistakes

• Looking at Invoices for “did we mark invoice sent?” when the office uses Accounts for that flag.
• Tariff 0. Send is refused.
• Missing customer email. Send is refused.

Payments

Payments in this module are money records tied to brokerage invoices (the Invoices module). They are not the Accounts screen’s payment status on the order, and they are not the platform subscription charge.

Who uses it

Accounts, Accounts Head, Admin, Sub Admin. Same desk as customer billing, different object than “mark this order paid” on Accounts.

Typical workflow

1. An invoice record exists for the order.
2. Record a payment against that invoice.
3. If your office also uses Accounts, update the order’s payment status there (pending, partial, paid, and so on) so the workbench matches reality.

What you can and cannot see

• You see payments on invoices you can access.
• You do not see Owner-platform charges for the CRM subscription.
• Commission paid-on is recorded on the Accounts workbench, not as a substitute for this payment record.

Related screens

• Invoices — parent records.
• Accounts — order-level payment status and commission paid-on.
• Orders — nested payments on the order are a related view, not a reason to skip Accounts.

Common mistakes

• Recording paid on Accounts but never creating the invoice/payment records (or the reverse) so two screens disagree.
• Training new billers that Payments and Accounts are the same button.

Accounts

Accounts is the billing workbench: orders in awaiting client signature, after a carrier has been assigned. Staff send the invoice (this is what marks invoice sent), then record payment status and commission paid-on. The view combines order and dispatch so billers see customer, tariff, carrier, and dates together.

Who uses it

Accounts, Accounts Head, Admin, Sub Admin. Sales should not treat this as their pipeline. Dispatch should not treat this as the board.

Typical workflow

1. Wait until the order is awaiting client signature. Earlier statuses do not belong here.
2. Open the row. Confirm customer email, tariff, and carrier.
3. Send invoice (optional email template). Payment status becomes invoice sent. The sender is recorded.
4. When money arrives, set pending / partial / paid / overdue / refunded / cancelled as needed, with method and amount.
5. Set commission paid-on: Slot booking, On dispatch, on Pickup, after delivery fee, or Partial payment — whichever the office agreed.

flowchart LR
  Pending --> InvoiceSent
  InvoiceSent --> Partial
  InvoiceSent --> Paid
  InvoiceSent --> Overdue
  Partial --> Paid
  Overdue --> Paid

What you can and cannot see

• Only orders awaiting client signature. Draft and awaiting-approval loads are invisible here.
• You see combined order + dispatch, stats (pending vs collected vs outstanding), and who sent the invoice.
• You do not mark invoice sent by emailing from the order screen.

Related screens

• Orders / Dispatch — operational source.
• Invoices / Payments modules — invoice objects vs this workbench flag.
• Email templates — optional invoice body.
• Customers — email and name must be right.

Common mistakes

• Tariff 0. Send invoice fails.
• Missing customer email. Send invoice fails.
• Using order send-invoice and then asking why Accounts still says pending.
• Looking for a load that is still pending approval. It is not on this workbench.
• Marking Partial with the full tariff. Use Paid for full payment.

Bulk operations

Select many rows in Leads, Quotes, Orders, or Dispatch and act once: reassign, convert leads to quotes, convert quotes to orders (preview first), or assign carriers (preview first; orders must already be approved). Maximum 100 records at a time.

Who uses it

Heads and Admin / Sub Admin doing desk moves. Sales with assign/convert access for their own board. Dispatch with assign access for the board. Same permission rules as the single-record buttons — bulk is not a bypass.

Typical workflow

1. Filter the list so you are not grabbing the wrong 100 rows.
2. Select up to 100.
3. Reassign: pick a user (sales for leads/quotes, dispatch for orders/dispatch) or clear assignment.
4. Leads → quotes: convert directly. Each lead still needs contact name and transport type, and must not already be converted.
5. Quotes → orders: run preview first. Fix pricing and skip already-converted quotes. Then commit.
6. Assign carriers: preview. Drop unapproved orders. Pick a carrier for every order that needs one. Then commit.

flowchart TD
  Select --> Reassign
  Select --> ConvertLeads
  Select --> PreviewQuotes
  PreviewQuotes --> ConvertQuotes
  Select --> PreviewCarriers
  PreviewCarriers --> AssignCarriers

What you can and cannot see

• You only bulk rows you can already see. Bulk does not reveal another team’s leads.
• Preview lists which quotes/orders are ready and which failed, with a human reason.
• You cannot send 101 ids. Split the batch.

Related screens

• Leads, Quotes, Orders, Dispatch — the tables you multi-select on.
• Users — who you reassign to. Do not pick a suspended user.
• Carriers — required for bulk assign.

Common mistakes

• Quote already converted in a mixed selection. Preview exists so you deselect it.
• Order not approved in a carrier batch. The assign is refused.
• Missing customer email on quote → order.
• Assuming bulk convert is a different business rule than single convert. It is the same rules, many times.

Marketing

Marketing runs campaigns and imports that can create leads. After a lead exists, sales work it in Leads like any other inquiry. Marketing is not a second CRM pipeline.

Who uses it

Marketing, Marketing Head, Admin, Sub Admin. Sales Head may see resulting leads, not necessarily campaign setup.

Typical workflow

1. Create a campaign or import a list according to the screens you have.
2. Leads appear in Leads (assignment and team still follow CRM rules).
3. Sales qualify and convert. Marketing does not price quotes unless they also have a sales role.

What you can and cannot see

• Marketing sees campaigns and imports they are allowed to run.
• They do not automatically see every sales quote or dispatch.
• Website capture is not this module — that is Public Lead Capture plus Settings / team origins.

Related screens

• Leads — where created inquiries land.
• Email templates — marketing-capable bodies if the office uses them for outreach.
• Customers — created when imported/created leads have email.

Common mistakes

• Importing without a vehicle or other item, then sales cannot treat it as a complete freight inquiry.
• Expecting marketing to convert to order. That is sales / create-order.
• Confusing campaign leads with website capture origins.

Calendar

Calendar is the shared schedule for follow-ups, pickups, and other timed work. The CRM also sends reminders at 1 hour and at 15 minutes before an event. Orders can carry calendar events on the order itself as well as this calendar.

Who uses it

Sales and dispatch for follow-ups and appointment times. Anyone who can open Calendar with their access. Reminders go to the people tied to the event — staff do not configure a mail server for this.

Typical workflow

1. Create an event with start time (and end if you use it), title, and who it belongs to.
2. Optionally add an event on the order when the time is load-specific.
3. Expect a reminder about one hour out and another at 15 minutes.
4. If you change the time, reminders fire against the new time.

What you can and cannot see

• You see events you are allowed to see — not necessarily the whole company calendar.
• You cannot turn off the 1 hour / 15 minute pair as a staff self-serve setting on the event beyond what the form offers.

Related screens

• Orders — nested calendar events on the load.
• Notifications — where reminders can appear in-app (and push if enabled).
• Dashboard — upcoming events in role-appropriate widgets.

Common mistakes

• Putting a pickup only in a personal phone calendar. The CRM reminders will not fire.
• Looking on Calendar for a time that was saved only on the order event list.

Notifications

Notifications are in-app bell items (live via SSE) plus optional web push if the tenant enabled it. Email may also fire depending on Settings. Mark one read or mark all read.

Who uses it

Everyone. You only get notified about work that involves you (assignment, approval needed, invoice sent, and similar). You do not get another desk’s full firehose.

Typical workflow

1. Watch the bell and badge. New items arrive without refresh.
2. Open one, or mark all read at the end of the day.
3. If the office wants browser push, allow notifications in the browser. Admin enables push in Settings / integrations as applicable.

What you can and cannot see

• Your items only.
• You cannot see Admin activity-log rows here. Different module.
• Push is optional. In-app still works if push is off.

Related screens

• SSE — delivery channel. Not configurable.
• Settings — in-app / email / push preferences at tenant level.
• Calendar — reminder notifications.
• Orders — approval requests for Dispatch Head / Admin.

Common mistakes

• Denying browser permission and reporting “push is broken.” In-app may still be fine.
• Expecting a notification for every field edit. Only meaningful events notify.

Email templates

Reusable email subjects and bodies for customer and carrier messages (quotes, invoices, dispatch, marketing). Department heads can create templates. Only the author can delete a template. Active templates are what most staff pick from when sending.

This is not the Templates module. Templates (sidebar) are paperwork packets synced from the Owner platform. Email templates are letters you send.

Who uses it

• Department heads create templates for their desk.
• Admin / Sub Admin see all templates (including inactive).
• Everyone else uses active templates when a send dialog offers them.
• Only the person who created a template can delete it.

Typical workflow

1. A head writes a template with placeholders for customer, order, tariff, and company name.
2. Leave it active so the desk can select it.
3. Accounts pick it when sending an invoice. Sales pick it when emailing a quote. Dispatch when emailing the load (before delivered).
4. To retire one, inactivate it. To remove it, the author deletes it.

What you can and cannot see

• Non-admins typically see active templates only.
• You cannot delete someone else’s template. Ask the author or an Admin to inactivate.
• You cannot use an email template to change Owner paperwork Templates.

Related screens

• Quotes — customer email.
• Orders / Dispatch / Accounts — send invoice (Accounts is the one that marks invoice sent).
• Settings — email integration is stored encoded. If mail never leaves, check Settings before rewriting the template.

Common mistakes

• A head deleting nothing because they did not author the row. Only the author can delete.
• Inactive template missing from a salesperson’s picker. Expected.
• Editing Email templates to “update the BOL form.” Wrong module — use Templates / eDocs.

Files

Files is the upload library: shared file records for the office. It is not the same as quote deal attachments, order packet files, or dispatch BOL / POD.

Who uses it

Staff who are allowed to upload and browse the library. Dispatch still uploads BOL on the dispatch. Sales still attach quote paperwork on the quote.

Typical workflow

1. Upload a file the office needs to reuse or store centrally.
2. Find it later in Files, not by opening a random load.
3. Put load-specific BOL on Dispatch. Put deal paperwork on the quote / order.

What you can and cannot see

• You see library files your access allows.
• You do not automatically see every dispatch BOL in Files.

Related screens

• Quotes / Orders — deal packet.
• Dispatch — BOL upload.
• eDocs — signed PDF stored on the quote (and related order / dispatch when those exist).

Common mistakes

• Training “everything goes in Files.” BOL will be missing on the load.
• Uploading a signed packet to Files instead of using eDocs on the quote.

Search

Top search finds records you are allowed to see: leads, quotes, orders, dispatch, and more, plus jump-by-number using lead, quote, order, dispatch, or tracking number. Recent searches are remembered for you.

Who uses it

Everyone with search. Results are scoped. A salesperson will not find another closer’s hidden lead. You never find yourself in people results.

Typical workflow

1. Type a name, email, city, or tracking / document number.
2. Open the result. Paths go to the record you can already access.
3. Reuse a recent search instead of retyping.
4. Empty search can still list navigation modules you are allowed to open.

What you can and cannot see

• Only modules and entities your role can read.
• Recent searches are yours, not company-wide.
• You cannot use search as an Admin back door.

Related screens

• Every pipeline module — destination of a hit.
• Nav counts — badges are not search.

Common mistakes

• QA logging “search is empty” on a sales user for an Admin-only invoice. Expected.
• Searching a converted lead number and expecting an active lead. Open the quote or order instead.

Knowledge base

Internal how-to articles for staff: office SOPs, how we price a lane, how we name loads. Not customer-facing and not eDocs.

Who uses it

Staff who can read articles. Authors / Admin who can write them. Customers never see this.

Typical workflow

1. Admin or a trained author publishes an article.
2. Staff search or browse when they are stuck.
3. Update the article when a process changes (for example “reject deletes the order”).

What you can and cannot see

• Internal articles only.
• This is not the signed customer PDF. That is eDocs.

Related screens

• Search — can hit knowledge base entries you are allowed to see.
• eDocs — customer signing, different product surface.

Common mistakes

• Pasting customer contracts into Knowledge base instead of sending an eDocs link from the quote.
• Leaving SOPs that say convert is a separate API button. In this CRM, you create an order from the quote.

AI pricing

Suggested price from origin, destination, and history. On a quote, staff also have the Aqua pricing helper. Treat both as a hint. The closer still owns tariff, carrier pay, and broker fee.

Who uses it

Sales and Sales Head when pricing a quote. Admin enables the integration. Dispatch does not use this to change quote vehicles.

Typical workflow

1. Open a quote with origin and destination filled.
2. Request a suggestion (AI and/or Aqua helper).
3. Override if the lane, vehicle, or enclosed vs open transport does not match history.
4. Never leave tariff at 0 because “AI will fill it later” if you intend to invoice.

What you can and cannot see

• A suggested number, not a locked rate.
• You cannot invoice on a zero tariff later even if AI was unavailable.

Related screens

• Quotes — where you apply the number.
• Settings — AI key stored encoded.
• Accounts — still requires tariff greater than zero.

Common mistakes

• Accepting a suggestion for the wrong transport type.
• Reporting AI as a product outage when the key is missing.

Analytics

Dashboards and charts for the brokerage. They differ by role. Sales see sales and commission-oriented numbers. Dispatch see dispatch-oriented numbers. Admin / Sub Admin see company charts, recent activity they are allowed to see, and approval queues. Totals follow the same visibility rules as the lists.

Who uses it

• Sales / Sales Head — pipeline and commission views.
• Dispatch / Dispatch Head — board and commission earned where that applies.
• Admin / Sub Admin — full dashboard charts and recent activity.

Typical workflow

1. Open Analytics / dashboard for your role.
2. Filter by month if the view offers it. Many totals are month-scoped.
3. Drill into Leads / Orders / Dispatch when a number looks wrong — confirm assignment before logging a counting bug.

What you can and cannot see

• You see charts built from records you can read.
• A salesperson’s “company revenue” is not Admin’s view.
• Admin’s own actions are not in Activity logs; do not expect Analytics to show a secret Admin audit of themselves there either.

Related screens

• Dashboard — home widgets vs this deeper analytics.
• Users — commission on sales/dispatch roles feeds commission charts.
• Accounts — collected vs outstanding is billing, not always the same widget.

Common mistakes

• Comparing a sales user’s dashboard to Admin and calling it a bug.
• Expecting converted (inactive) leads to still count as open work.

Nav counts

The numbers on the left menu for leads, quotes, orders, and dispatch you can read. They are badges, not a second dashboard. They drop when you open that list (as the product counts unread / outstanding the way the CRM defines it) and they respect visibility.

Who uses it

Anyone with those modules. Sales badges are not Dispatch Head’s badges.

Typical workflow

1. Glance at the sidebar to see whether new work landed (live via SSE).
2. Open the list. Work the rows. Counts follow.

What you can and cannot see

• Counts only for lists you can read.
• They are not Accounts revenue and not Analytics charts.

Related screens

• Leads, Quotes, Orders, Dispatch.
• SSE — badges update without refresh.

Common mistakes

• QA expecting a sales badge to include another team’s leads.
• Using badges as a month-end report.

Templates

Paperwork templates pushed from the Owner platform: the packet customers sign and the office prints. Tenant Admins apply a new version when Owner publishes one. This is not Email templates.

Who uses it

Admin / Sub Admin apply updates. Staff use the resulting packet through eDocs and the quote. Sales do not edit Owner templates as if they were a Word inbox.

Typical workflow

1. Owner publishes a new version.
2. Tenant Admin reviews the difference and applies it.
3. Staff send sign links from quotes using the current packet.

What you can and cannot see

• Admins see that an update is waiting.
• You cannot create an Owner template from Email templates.

Related screens

• Admin — plan and feature sync.
• eDocs — customer signing surface.
• Quotes — where staff send the sign link.
• Email templates — unrelated letters.

Common mistakes

• Renaming the two modules in training. People will edit the wrong one.
• Sending eDocs before applying a published template update the office meant to use.

Settings

Company profile for the tenant: company name, timezone (default America/Chicago), website origins for capture, IP allowlist (Admin), and integrations (AI key, email, maps) stored encoded. Notification channel defaults also live here.

Who uses it

Admin and Sub Admin change most of these. IP allowlist is an Admin control. Other staff may view company name and timezone they work in, but they should not edit origins or keys.

Typical workflow

1. Set company name and timezone. Default timezone is America/Chicago if you never change it. Dates and reminders follow this.
2. Add website origins on the Origin tab so capture is allowed. Add the same kind of origin on a team if that site should route to the team.
3. Admin: IP allowlist if the office must only sign in from known networks. A wrong list locks people out, including you.
4. Paste AI, email, and maps credentials. The CRM stores them encoded. Staff never copy them into a chat.
5. Copy Tenant ID from Profile (Admin / Sub Admin) when a developer or marketer sets up Public Lead Capture.

What you can and cannot see

• Integrations are stored encoded. You should not see raw secrets in ordinary UI.
• Tenant ID is on Profile for Admin / Sub Admin, not buried as a permission string.
• eDocs origin must also be allowed or customers cannot open the sign site.

Related screens

• Teams — team-level origins.
• Auth — IP allowlist can block login.
• AI pricing — needs the AI key.
• Email templates / invoice send — need email integration.
• eDocs — origin allowlist.

Common mistakes

• Origin blocked: form posts fail, no lead, eDocs may fail to open.
• Timezone left on Chicago while the office is elsewhere — reminders look “an hour off.”
• IP allowlist with only one home IP, then nobody in the warehouse can sign in.
• Putting origins only in a spreadsheet, never in Settings or the team.

Public profiles

Each staff member can share a personal URL from Profile. The public id looks like u- followed by eight digits. That page is public. It does not grant CRM access and does not require login.

Who uses it

Staff who want a shareable page (sales cards, email signatures). Anyone on the internet with the link can open it. Customers still cannot see other people’s leads.

Typical workflow

1. Open Profile. Copy the public profile link.
2. Share it. Viewers see the public page only.
3. Do not send this link as a substitute for an invite or for eDocs.

What you can and cannot see

• Viewers see the public profile, not User Management, not the pipeline.
• Staff still never see themselves in the people list; this URL is from Profile.

Related screens

• Profile / Auth.
• Users — invites are the way to grant login.
• eDocs — signing is a different public site.

Common mistakes

• Treating the public page as “they can log in now.”
• Putting Tenant ID on a public profile. Tenant ID stays on Admin / Sub Admin Profile for capture setup.

eDocs

eDocs is the customer signing site. Staff send a sign link from a quote. The customer opens it (no CRM login), verifies who they are, and signs. The signed PDF is stored on the quote and on the related order or dispatch when those records exist. The eDocs site origin must be allowed.

Who uses it

• Sales send the link from the quote when paperwork is ready.
• The customer signs on eDocs.
• Accounts and dispatch consume the signed PDF later. They do not re-collect wet ink for the same packet.

Typical workflow

1. Quote is complete: contact, email, vehicles or other items, price.
2. Staff send the sign link from that quote (eDocs uses the quote, not a random order number).
3. Customer opens the allowed eDocs origin, verifies, signs.
4. CRM stores the signed PDF on the quote; order / dispatch pick it up when they exist.
5. Accounts still send invoice separately when the order is awaiting client signature.

flowchart LR
  Quote --> SignLink
  SignLink --> Customer
  Customer --> SignedPDF
  SignedPDF --> Quote
  SignedPDF --> Order
  SignedPDF --> Dispatch

What you can and cannot see

• Staff see that a link was sent and that a signed PDF exists on the quote.
• Customers never see the CRM sidebar.
• Origin must be allowlisted. This is the same class of problem as blocked lead capture.

Related screens

• Quotes — send link.
• Orders / Dispatch — signed PDF when the load exists.
• Settings / Teams — allowed origins.
• Templates — Owner paperwork packet, not the email letter.
• Accounts — billing after client signature, not the signature itself.

Common mistakes

• Origin blocked — customer reports a blank or refused sign site.
• Missing customer email — staff cannot send the link.
• Sending a link from the wrong quote after a duplicate conversation.
• Expecting eDocs to mark invoice sent. It does not. Accounts send-invoice does.

Desktop app

Signed-in staff can download the Windows desktop client from the CRM while they are logged in. It is the same brokerage CRM, not a customer app.

Who uses it

Staff whose tenant offers the download. You must already be able to sign in. Customers do not download this from eDocs.

Typical workflow

1. Sign in to the CRM in the browser.
2. Download the Windows app from the sidebar / download control.
3. Install and sign in with the same staff account.

What you can and cannot see

• The same visibility rules as the web CRM (sales-owned vs dispatch-assigned, and so on).
• You cannot download while logged out. The installer endpoint is for signed-in staff.

Related screens

• Auth — same login.
• Notifications / SSE — live updates still apply in the product.

Common mistakes

• Emailing the installer to a customer. Wrong audience.
• Asking a suspended user to “just use the desktop app.” Suspended is still suspended.

Activity logs

Who changed what in the CRM: a business-facing trail of staff actions. Admin and Sub Admin only. Admin’s own actions are not recorded. This is not the raw HTTP request log.

Who uses it

Admin and Sub Admin. Sub Admin viewing is still privileged and does not include the same “see myself / other sub admins” cases the product hides. Everyone else should not expect this menu.

Typical workflow

1. A salesperson converts a lead or an accounts user sends an invoice.
2. Admin opens Activity logs to see who did it, from which department, and when.
3. Do not use this to debug a 500 or a blocked origin — that is Request logs or capture settings.

What you can and cannot see

• Actions by non-Admin staff.
• Not Admin’s own actions.
• Not payload dumps. Not Swagger.

Related screens

• Request logs — raw API traffic for troubleshooting.
• Users — who the actor is.
• History on a lead / quote / order — record-level notes, complementary but not this list.

Common mistakes

• QA as Admin performing a convert, then failing the test because Activity logs are empty for that action.
• Training sales to “check the activity log.” They cannot.

Request logs

Raw API traffic for troubleshooting: what was called, when, and how it finished. Admin and Sub Admin only. Use Activity logs for business “who changed what.” Use Request logs when capture is blocked, a send invoice 400 needs a reason, or QA must prove a call happened.

Who uses it

Admin, Sub Admin, and whoever they sit with (developer, QA). Not a sales tool.

Typical workflow

1. Reproduce the failure (origin blocked, tariff 0 invoice, unapproved carrier assign).
2. Open Request logs and find the timestamp.
3. Fix the business data (email, origin, approval) rather than “retrying harder.”

What you can and cannot see

• Technical request history for the tenant.
• Not a substitute for telling a salesperson which button to click.
• Health checks may appear as traffic and are not CRM work.

Related screens

• Activity logs — people and actions.
• Settings — origins, IP allowlist, integrations.
• Swagger — how a call is supposed to look (developers).
• Docs hub Health — up/down only.

Common mistakes

• Reading Request logs to decide commission. Wrong module.
• Ignoring a 400 that already says missing email or invalid tariff, then filing “email never sent” as a mail-server bug.