Skip to content
English
Contact us
  • There are no suggestions because the search field is empty.

Warehouse — HubSpot — Delivery & Pickup Tickets: Completion and Partials

How warehouse and delivery teams use Delivery and Pickup tickets to complete jobs, record partials, and trigger Needs Attention when something goes wrong.

Audience

  • Delivery drivers, warehouse staff, and dispatch.

  • Warehouse leads who monitor last‑mile fulfillment.

Purpose / When to use this

Use this article whenever you are working Delivery or Customer Pick Up tickets in HubSpot.
It explains when these tickets are created, what the stages mean, and how to record complete vs partial outcomes so Needs Attention and other exceptions are triggered correctly.

1. What Delivery & Pickup tickets are

  • A Delivery ticket tracks taking finished product from the warehouse to the customer.

  • A Customer Pick Up ticket tracks customers coming to the warehouse to pick up product.

They are created automatically as the final stage of the warehouse chain, but their creation does not guarantee the job is ready to go.

KEY IDEA: The existence of a Delivery or Pick Up ticket means “this job is moving toward last‑mile,” not “every single item is ready.” You must check outstanding warranties, backorders, and notes first.

 

2. When Delivery & Pickup tickets are created

2.1 Deals with assembled cabinets

For deals with assembled cabinets:

  • The system waits for the Build ticket to have Status = Complete.

  • As soon as the Build ticket is marked Complete:

    • Delivery and/or Customer Pick Up tickets are created for that deal.

    • This happens even if Build Completion Status is still awaiting warranties/backorders.

Effect:

  • Delivery/PU planning can start once everything currently in‑house has been built.

  • Outstanding warranty/backorder work is tracked via Build and related tickets.

2.2 Deals without assembled cabinets

For deals without assembled cabinets:

  • There is no Build step. Delivery/PU tickets are created from Receive.

  • As soon as the first Receive ticket for that deal is marked Check-in Complete (even if partial):

    • Delivery and/or Customer Pick Up tickets are created.

Effect:

  • Delivery/PU planning can start once everything currently in‑house has been built.

3. Shared first step: double‑check the job before scheduling

Whenever a Delivery or Pick Up ticket is created, the first step is not to schedule immediately, but to double‑check the order:

From the Delivery / Customer Pick Up ticket:

  • Review the summary dashboards, similar to Build tickets:

    • Existing Warranty tickets.

    • Order tickets.

    • Receive tickets and their completion status.

    • Build completion status (for assembled jobs).

This gives you a quick view of:

  • Outstanding warranties that still need parts.

  • Known backorders still in transit.

  • Whether anything obvious is missing before you plan dates.

KEY IDEA: There can be a “holding pattern” at the start of Delivery/PU where you’re waiting on warranty parts or backorders. The ticket exists so you can plan, but you should not assume the job is ready until the summaries look clean.

4. Delivery pipeline: stages and intent

Delivery pipeline statuses:

  1. Awaiting Double Check

  2. Double Checked

  3. Date Confirmed

  4. Pre-Delivery Confirmation

  5. Final Check and Load

  6. Out For Delivery

  7. Complete

Each stage has dependent properties you must fill out (completion statuses, dates, windows, notes, etc.), which in the future will drive automated customer notifications (email/SMS).

4.1 Awaiting Double Check → Double Checked

  • Awaiting Double Check

    • Initial stage after ticket creation.

    • Delivery team reviews the ticket summaries:

      • Warranties outstanding?

      • Backorders still in transit?

      • All required cabinets built?

    • If unresolved items remain, the job may sit here in a holding pattern while parts arrive.

  • Double Checked

    • Once you confirm you understand:

      • What is ready now,

      • What (if anything) is still outstanding and how it will be handled,

    • Update dependent fields (e.g., internal notes) and move to Double Checked.

4.2 Date Confirmed

  • At Date Confirmed, you have agreed on a target delivery date (and possibly window) with dispatch and/or the customer.

  • Dependent properties:

    • Delivery Date / Window.

    • Any additional scheduling notes.

This stage is a key anchor for future automated customer notifications (“Your delivery is scheduled for…”).

4.3 Pre-Delivery Confirmation

  • Used for pre‑day checks:

    • Confirm job is still on schedule.

    • Confirm truck routing.

    • Optionally confirm with customer the day before.

Dependent properties might include:

  • Confirmation timestamp.

  • Notes about access, gate codes, etc.

4.4 Final Check and Load

  • This is the warehouse loading checkpoint:

    • Verify all items that should go on the truck are pulled and staged.

    • Confirm against the DEL sheet and any notes.

If anything is missing/damaged at this stage:

  • Document it and determine if the delivery will be partial or needs to be rescheduled.

  • This is where you decide if you can still move to Out For Delivery or must hold.

4.5 Out For Delivery → Complete

  • Out For Delivery

    • Truck has left the warehouse with the job on board.

  • Complete

    • Job is finished from the delivery perspective.

    • Completion‑status dependent property should be set to:

      • A true complete value if all items were delivered successfully, or

      • A partial/failed value if anything went wrong (see section 6).

REMINDER: The future goal is to tie email/text updates to these stages (Date Confirmed, Out For Delivery, Complete). That only works if statuses and dependent properties are filled out correctly each time.

5. Customer Pick Up pipeline: stages and intent

Customer Pick Up pipeline statuses:

  1. Awaiting Double Check

  2. Double Check Complete

  3. Customer Notified

  4. Awaiting Customer

  5. Pickup Complete

Each stage has dependent properties (notes, dates, completion statuses) and will also be used for future automated customer notifications.

5.1 Awaiting Double Check → Double Check Complete

  • Awaiting Double Check

    • Initial state after ticket creation.

    • Review ticket summaries (warranties, backorders, build/receive status) to understand what’s ready.

  • Double Check Complete

    • Once you know what’s ready and what is still outstanding, and how that will be handled for pickup, move here.

5.2 Customer Notified → Awaiting Customer

  • Customer Notified

    • Customer has been told that their order (or part of it) is ready for pickup.

    • Dependent properties:

      • Notification date.

      • Any specific instructions (vehicle size, dock, etc.).

  • Awaiting Customer

    • Items are staged or ready to be staged.

    • You’re waiting for the customer to arrive.

In the future, moving through these stages can drive outbound messages (“Your order is ready for pickup”).

5.3 Pickup Complete

  • Set when the customer has arrived and picked up the items.

  • Completion‑status dependent property should indicate:

    • Complete — customer received everything expected, or

    • A partial/failed value if some items were not released (e.g., customer declined, missing/damaged items).

6. Recording complete vs partial/failed outcomes

Both Delivery and Customer Pick Up tickets rely on a Completion Status (or equivalent) that describes the outcome:

  • Complete — all items successfully delivered/picked up; no outstanding issues.

  • Partial — some items delivered/picked up; some not.

  • Damaged / Missing / Customer Not Home — specific failure reasons.

6.1 When to treat as truly complete

A Delivery or Pickup is truly complete when:

  • All items that were supposed to go out in this job were successfully delivered/picked up.

  • Any exclusions (backorders, known warranties) were:

    • Already accounted for upstream (Receive/Build/Warranty), and

    • Not expected as part of this particular trip.

In this case:

  • Final stage (Delivery: Complete, Pickup: Pickup Complete).

  • Completion Status = Complete.

  • Ticket can drop off the Current Deliveries / Current Pickups views.

6.2 When to mark partial or failed

If anything goes wrong at last mile:

  • Not all items made it to the customer.

  • Customer not home or refuses delivery.

  • Items discovered missing or damaged at delivery/pickup.

Then:

  1. Set Completion Status to an appropriate partial/failed value.

  2. Add clear notes with:

    • Exactly which items were delivered/picked up vs not.

    • Why they were not delivered/picked up.

    • Any photos and details needed for sales to follow up.

  3. Leave the ticket visible in the view until the underlying issue is resolved and Completion Status is updated to Complete.

KEY IDEA: Status shows where you are in the process. Completion Status tells the truth about the outcome. Partial or failed outcomes must always be accompanied by detailed notes.

7. How partials trigger Needs Attention / follow‑up

When Delivery or Pickup tickets end in a partial/failed outcome:

  • The system can generate a Needs Attention ticket for the sales rep.

  • That Needs Attention ticket:

    • Links back to the Delivery/Pickup ticket.

    • Tells the rep what went wrong (using your notes).

    • Keeps them responsible for fixing the customer problem.

Your responsibilities:

  • Document clearly on the Delivery/Pickup ticket:

    • “Customer not home; door tag left; needs reschedule.”

    • “Missing 2x uppers; not on truck; confirm if still at warehouse or vendor.”

    • “Door damaged on site; requires warranty.”

  • Use @‑mentions to tag @Sales, @Dispatch, or @WarehouseLead as appropriate.

8. When a Delivery or Pickup ticket leaves the queue view

Delivery/Pickup tickets should only drop off their active views (Current Deliveries / Current Pickups) when:

  • They are in their final stage (Delivery: Complete, Pickup: Pickup Complete), and

  • Completion Status is a true complete value (not Partial, Missing, Damaged, etc.).

If Completion Status is anything else:

  • The ticket remains visible as an open or exception job until the underlying problem is resolved and Completion Status is updated.