skills-source-products/delay-list-skill/SKILL.md at 6d5b66578989e26d6f1ebfafe9cab26c69d529d1

claude-skills/skills-source-products

Fork 0

Files

T

thijs.kuipers 6d5b665789 Multiple updates on how to find orders in hubspot and exclude for example Aircall Tickets

2026-04-10 08:42:50 +02:00

26 KiB

Raw Blame History

name, description

name	description
delay-list-processor	Daily delay list processing skill for the traffic team. Fetches the delay list via API, categorizes orders, auto-snoozes packaged orders from known suppliers, sends bundled supplier emails, notifies customers, logs complaints, and updates tracking. Use this skill whenever the user mentions: delay list, delayed orders, dispatch delays, snooze orders, supplier outreach, delay processing, traffic team workflow, daily delays, or order not shipped. Also trigger when the user asks to process delays or check today's delays.

name

description

delay-list-processor

Daily delay list processing skill for the traffic team. Fetches the delay list via API, categorizes orders, auto-snoozes packaged orders from known suppliers, sends bundled supplier emails, notifies customers, logs complaints, and updates tracking. Use this skill whenever the user mentions: delay list, delayed orders, dispatch delays, snooze orders, supplier outreach, delay processing, traffic team workflow, daily delays, or order not shipped. Also trigger when the user asks to process delays or check today's delays.

Overview

Each day, orders that have surpassed their expected dispatch date appear on the delay list — whether still in production or packaged. This skill processes that list systematically: auto-snoozing where safe, emailing suppliers (bundled per supplier), notifying customers, logging complaints, and flagging edge cases for human review.

Scale: ~4,000 orders/day, delay list can be extensive.

Inputs

Delay List — Fetched via the Delay List API (not a file upload). The API returns the current delay list with the following fields per order:
- Order (order number)
- id_order_detail (order line ID)
- Assigned (team member or blank)
- Status (Open, Customer Informed, Checking, etc.)
- Delay Reason (No delay reason given, Email Sent to Supplier, etc.)
- New Target Dispatch (updated date if any)
- Product (product type/SKU)
- Supplier (supplier name)
- Sales Price
- State (production/packaging state — see values below)
- Delay (days past target dispatch)
- Carrier (carrier name if available)
- Tracking Link (if available)
- Target Dispatch Date
- Actual Dispatched Date
- Latest Delivery Date
- shop_country_code
- Shop_name
- Supplier Order number
- Postcode
Operator context — Any special notes for the day (supplier outages, holidays, known issues).
Supplier Complaint Classification Spreadsheet — Reference for whether a supplier is volume-based (zero cost complaint) or discount-based (10% discount complaint). Read from references/supplier-classification.md if available.

Processing Workflow — Execution Order

Process in this exact order to ensure data is fresh for downstream decisions:

Step 1: Fetch & Validate the Delay List

Call the Delay List API to retrieve today's current delay list
Validate expected fields are present in the API response
Flag any records with missing critical data (Order, Supplier, State) for MANUAL_REVIEW
Calculate correct delay days: business days between Target Dispatch Date and today (note: the system's built-in delay count can be incorrect — see Edge Cases)

Step 2: Auto-Snooze Packaged Orders (High Confidence)

Criteria — ALL must match:

Field	Required Value
State	`Your order has been packaged`
Target Dispatch Date	Previous working day
Carrier	One of: `UPS-UPS_STANDARD`, `UPS-UPS_SAVER`, `DPDINT-STANDARD_UK`, `DPDINT-STANDARD`, `CORREOS-STANDARD`
Tracking Link	Must be present (non-empty)
Supplier	One of the approved auto-snooze suppliers (see list below)

Attention Always pass the full raw API response into the filter. Never manually subset the data before filtering. Validate record counts before executing any snoozes.

Approved Auto-Snooze Suppliers:

De Groot Drukkerij B.V.
The Postermen
Intervlag
Vila Etiketten
VG Print B.V.
Zalsman B.V.
Oakdene Services
I print 1925
Digiforce
Enson
Probo
Promio
Inpromo
Today's Media
Pressing
Drukkerij Van As
Oakdene Services

Action: If you want to snooze an order call traffic-mcp snooze-order workflow. with a body like this: { orderDetailId: %id_orderdetail% }

Action: Sent information to traffic-mcp with call slack-feed-traffic-delay-list. Use the format below.

Slack Message Format for Snoozed Orders

When posting snoozed order results to Slack, always use this exact format with Slack mrkdwn syntax.

1. Header

A bold line with the total count:

*Here are all {count} snoozed orders:*

2. Table

Wrap the table in a Slack code block (triple backticks) so columns stay aligned:

Use | as column separator for readability
Include every order — never truncate or summarize with "and X more"
Column order is fixed: Order Detail ID → Supplier → Carrier → Product
The header count must match the actual number of rows

3. Summary footer

After the code block, add a summary line in italic:

_All had state "Your order has been packaged", target dispatch date of March 13, and valid tracking links._

If orders have different states or dispatch dates, group them:

_• {count} orders with state "{state_a}", target dispatch date of {date_a}_
_• {count} orders with state "{state_b}", target dispatch date of {date_b}_
_All had valid tracking links._

Posting Rules & Slack Character Limit

Slack has a ~4000 character limit per message. If the full table exceeds 25 rows, you must split it into multiple messages to prevent the code block formatting from breaking. Don't send the message as json.

Important — Slack message formatting: Always send message text with actual line breaks, not \n escape characters. If you type \n literally in the input, the entire message will appear as one long line in Slack. Write the message across multiple lines in the input field itself

Splitting logic:

Calculate the number of parts needed: ceil(total_rows / 25)
Each message must be a self-contained code block (with its own opening and closing triple backticks)
First message starts with the bold header: *Snoozed orders (part 1/{total_parts}):*
Middle messages use: *Snoozed orders (part X/{total_parts}):*
Last message includes the italic summary footer after the code block
If all orders fit in a single message (≤25 rows), use the standard header: *Here are all {count} snoozed orders:*

Example with 56 orders (3 parts):

Message 1:

*Snoozed orders (part 1/3):*
``` ```
Order Detail ID | Supplier                    | Carrier            | Product
5768484         | De Groot Drukkerij B.V.     | DPFINT-STANDARD    | foldedleafletsv2
...rows 1-25...
``` ```

Message 2:

*Snoozed orders (part 2/3):*
``` ```
Order Detail ID | Supplier                    | Carrier            | Product
...rows 26-50...
``` ```

Message 3:

*Snoozed orders (part 3/3):*
``` ```
Order Detail ID | Supplier                    | Carrier            | Product
...rows 51-56...
``` ```
_All had state "Your order has been packaged", target dispatch date of March 13, and valid tracking links._

Send each part as a separate call to mcp__traffic-mcp__Call_slack-feed-traffic-delay-list_.

Confidence: If ALL criteria match exactly → auto-execute (99%+ confidence). If any field is ambiguous or missing → MANUAL_REVIEW.

Step 3: Supplier Outreach — "In Production" Past Dispatch

Criteria

Dispatch date has passed
State = Your order is in production OR Ready for production
No tracking information

Pre-check (if HubSpot integration available)

Check HubSpot for existing communication on the order item using the mandatory 3-step search below. Then categorize each order:

If email found explaining delay WITH reason → print reason in chat with order, skip outreach email
If email found but NO reason provided → print new dispatch date in chat with order_id, add order to markdownfile per supplier.
If email shows internal issue (e.g., artwork, stock) → tell which orders are internal reason.
If no email found → add order information to markdown file

CRITICAL — Skip Aircall tickets: Tickets with a subject matching "Aircall new ticket" or containing "Aircall" are auto-generated phone call logs and should be ignored entirely. Do not count them as HubSpot hits and do not include them in any category. If an order's only HubSpot result is an Aircall ticket, treat it as having no HubSpot hit (i.e. it should go to supplier outreach).

CRITICAL — Informational-only tickets do NOT count as actionable hits. Many orders have HubSpot tickets that are purely informational and do NOT indicate that the delay has been communicated to or acknowledged by the supplier. When an order's only tickets are informational, treat it as having no actionable HubSpot hit — it must go to supplier outreach.

Informational-only ticket types (ignore for categorization):

Supplier order confirmations — e.g. "Order confirmation Showdown Displays", "Solo midocean Order confirmation", "Bestelling Ontvangen", "Auftrag … zu Bestellung", "Your Bullet Sales Order#", "O- 003-FSSE-…" (PF Concept), "Order … ontvangen voor klant" (Primex). These confirm the order was placed, not that the delay is being handled.
Auto-generated "in production" / "being printed" emails — e.g. "Your project is being printed", "Bestelling in Drukproces". These are automated supplier pipeline notifications, not responses to a delay inquiry.
Shipping date expectation emails sent BEFORE the dispatch date passed — e.g. "Verwachte verzenddatum", "Shipping date expectations", "BIC Graphic Confirmation: Your Shipment Date". These were sent at order acceptance, not in response to a delay.
Auto-replies / out-of-office — e.g. "Automatic reply:", "Out of Office".
Proof/design sent emails — e.g. "Bestel ontwerp", "Print proof update". These are part of the normal order flow, not delay communication. (Exception: if the proof is still awaiting approval and is blocking production, that IS actionable — categorize as "other_status".)

Actionable ticket types (DO count as real HubSpot hits):

Delay explanations with reason (e.g. "delayed dispatch", "Vertraging:", "We're sorry, job X is delayed")
Artwork issues blocking production (e.g. "ARTWORK REFUSAL", "artwork query", new file needed)
Stock/production issues (e.g. "STOCK DIFFERENCE", "creation failed", "update failed", "retry attempt")
Internal Helloprint issues (e.g. "AutoCheck Declined", "Speed Up Request")
Complaint tickets (e.g. "Your complaint")
Any ticket where a human wrote about the specific delay or a problem with the order

Multi-ticket handling: When an order has multiple tickets, apply this logic:

Filter out Aircall tickets entirely.
Classify each remaining ticket as either "informational" or "actionable" using the lists above.
If ALL remaining tickets are informational → treat as no HubSpot hit → order goes to supplier outreach.
If at least one ticket is actionable → use the most recent actionable ticket (by createdate) to determine the order's category.
In the PDF report, show the primary (most recent actionable) ticket ID and note the total ticket count (e.g. "413360096501 (+2 more)").

CRITICAL — Supplier name sourcing: When categorizing HubSpot results, ALWAYS use the supplier_name from the delay list order data — never derive the supplier name from the HubSpot ticket subject. Ticket subjects often reference sub-brands, parent companies, or intermediary names (e.g. "Oakdene" instead of "Solopress v2") which do not match the actual supplier on the order.

HubSpot Search Strategy (MANDATORY — execute ALL 3 steps)

The hp_order_line_id and hp_order_id fields in HubSpot frequently contain multiple comma-separated values in a single field (e.g., "9155560, 9162986"). IN/EQ filters only match when the field contains exactly one value, so they will miss multi-value fields. All 3 steps below are required — skipping step 3 consistently causes 10-20% of tickets to be missed.

Step 1 — Batch IN-filter on hp_order_line_id Search tickets using IN operator on hp_order_line_id with batches of max 50 detail IDs. Record which detail IDs got a hit.

Step 2 — Batch IN-filter on hp_order_id For all orders where NO hit was found in step 1: search tickets using IN operator on hp_order_id with batches of max 50 order IDs. Record which orders got a hit.

Step 3 — Individual full-text query search (DO NOT SKIP — execute for ALL orders) Execute this step for every id_order_detail — including those that already had a hit in step 1 or 2. A step 1/2 hit may find a different ticket (e.g. an Aircall ticket or generic auto-created ticket) than the one containing the actual supplier communication. Multi-value hp_order_line_id fields (with 50-100+ comma-separated IDs) are common for bundled supplier emails and are only matchable via query.

For each id_order_detail: search tickets using the query parameter (not a filter) with the individual detail ID as search string. If that returns 0, also try the id_order. Merge all results from steps 1, 2, and 3 — do not discard earlier hits, but ensure the full picture of tickets per order is captured.

Why this matters: In practice, many supplier outreach emails reference dozens of orders in a single ticket with a multi-value hp_order_line_id. The IN filter cannot match these. Step 2 may find only tangentially related tickets (Aircall, auto-generated). Without step 3 on ALL orders, you will miss the actual supplier email thread and either miscategorize orders or send duplicate outreach.

Supplier-Specific Handling

Before creating generic outreach emails, check if the supplier has a specific workflow:

Probo

False delay check (automated): Probo orders often trigger false delays when multiple order lines are shipped together. Check Presta for linked order lines:
1. Gather all linked order lines for the order
2. Check the "despatch" tab on all order lines
3. If lines were shipped together → remove from delay list (false delay)
Portal status check (manual): The Probo portal is not accessible to the AI. List all remaining Probo delayed orders (after false-delay filtering) in a separate "Manual Action Required — Probo" section so the operator can verify actual production status in the Probo portal.
Probo delay email received in HubSpot → Flag these orders: update to "not sent on time", note the need to follow up for a new dispatch date.
Outreach: Do NOT include Probo orders in the generic supplier email drafts. All Probo follow-up is handled via their portal or based on portal findings.

Flyeralarm

Any delay → Do NOT send an outreach email and do NOT include in the supplier email drafts. Flyeralarm delays are handled via their own supplier portal (case creation), which requires manual access.
Action: List all Flyeralarm delayed orders in a separate "Manual Action Required — Flyeralarm" section in the output so the operator can handle them in the portal.

Masterprint

Skip entirely — Masterprint tracking is already automated. Orders packaged on the Masterprint tracking sheet are auto-removed from the delay list. No outreach needed.

Action

For all remaining suppliers (not covered by supplier-specific handling above), create drafts with emails per supplier so we can review them.

CRITICAL RULE — No duplicates in outreach: Before generating supplier outreach emails, EXCLUDE every order that already appears in a HubSpot category (Section 1) with an actionable ticket. Only orders with zero actionable HubSpot hits (including those with only informational tickets) should appear in the outreach email drafts. An order must never appear in both the HubSpot Analysis section and the Supplier Outreach section.

CRITICAL RULE: Bundle emails per supplier. Never create multiple emails to the same supplier. Group all delayed order lines for a supplier into ONE email.

Email Template

Always use the following template for supplier outreach emails:

Hi Partner,

The orders listed below were due to be dispatched on the agreed target date, however they appear to not have been completed or sent yet.

[TABLE]

Please could you provide an urgent update on the current status of these orders and confirm when they will be ready for dispatch?

Thank you, and we look forward to your prompt response.

The [TABLE] must have exactly these 5 columns:

Column	Content	Format
Order	Combined order + detail ID	`{id_order}-{id_order_detail}` (e.g. `5831128-9215018`)
Target Dispatch Date	The agreed dispatch date	`DD Mon YYYY` (e.g. `31 Mar 2026`)
Product	Product type/SKU	As returned by API
Supplier Order	Supplier's own order number	Only if provided, otherwise omit column or show `-`
Carrier	Intended carrier	As returned by API

Do not deviate from this template. Do not add extra paragraphs, bullet points, or numbered lists asking for specific information — the template already covers everything needed.

Logging & Tracking

Every action must be logged. No exceptions.

Processing Log

Maintain a structured log (CSV) saved to the outputs directory with the following fields per order processed:

Field	Description
`timestamp`	ISO 8601 timestamp of action
`order_id`	Order number
`id_order_detail`	Order line ID
`supplier`	Supplier name
`product`	Product type
`state`	Order state at time of processing
`delay_days`	Calculated delay in business days
`category`	Action category (see list below)
`action_taken`	Specific action executed
`confidence`	Confidence percentage
`auto_or_manual`	AUTO / FLAGGED_FOR_REVIEW
`human_decision`	Operator decision if flagged (blank if auto)
`batch_number`	Batch ID
`status`	SUCCESS / FAILED / PENDING_REVIEW
`error_details`	Error info if failed
`email_sent_to`	Supplier/customer email triggered
`email_bundled_with`	Other order IDs in same supplier email
`complaint_logged`	true/false
`complaint_type`	Carrier / Supplier
`complaint_cost`	Zero / 10% discount
`snooze_hours`	Hours snoozed
`notes`	Additional context

Daily Summary Report

Generate at end of processing and save as a file:

Total orders on delay list and total processed
Breakdown by action category (counts and percentages)
Auto-processed vs. flagged for review (counts)
Supplier emails sent — count and list of suppliers contacted
Customer notifications sent — count
Complaints logged — carrier vs. supplier, with cost breakdown
Orders snoozed — count and average snooze duration
Failed actions with details
Pending manual review — full list with proposed actions
Top delayed suppliers — ranked by number of delayed orders
Orders delayed 3+ days — highlighted for urgency

PDF Report Generation

After completing Step 3, generate a professional PDF report using reportlab. The PDF serves as the primary deliverable for the traffic team to review and act on. Install with pip install reportlab --break-system-packages if not available.

PDF Structure

The report has three main sections, each starting on a new page:

Page 1 — Cover & Summary

Title block with dark background: "Delay List Report — Step 3: Supplier Outreach Analysis" + date
Summary stat cards in a grid layout showing: Total Orders, HubSpot Hits, Need Outreach, Internal Issues, Masterprint (Skipped), Flyeralarm (Manual), Probo (Manual), Suppliers to Contact
Caveat note about HubSpot search scope limitations

Section 1 — HubSpot Analysis Colour-coded tables categorising orders with existing communication:

1.1 Internal Issues (red header) — orders blocked by artwork errors, API failures, retry limits, price disputes. These need Helloprint action, not supplier outreach.
1.2 In Production / On Track / Reprints (green header) — orders confirmed in production or with reprints underway. No outreach needed.
1.3 Other Statuses (blue header) — shipped, awaiting approval, customer issues, unclear status.
1.4 HubSpot Tickets Found — Review Needed (orange header) — tickets exist but need manual review to determine action.

Each table has 4 columns: Ticket ID (the real HubSpot hs_ticket_id), Order Detail ID (id_order_detail), Order ID (id_order), Details (summary of the issue/status). The Ticket ID must be the actual HubSpot ticket identifier — do NOT use the id_order_detail as Ticket ID. When performing the HubSpot search, always store the returned hs_ticket_id alongside the matched hp_order_line_id / hp_order_id so they can be rendered correctly in the report. Use Paragraph flowables for the Details column to allow text wrapping.

Section 2 — Manual Action Required

Flyeralarm — order table with note that portal case creation is required
Probo — order table with note to verify in Probo portal
Masterprint — count + note that tracking is automated

Section 3 — Supplier Outreach Emails For each supplier (sorted by order count descending):

Supplier heading with order count
Draft email using the standard email template (see Email Template section above)
Embedded order table within the email block

PDF Styling

Use these design principles for a clean, professional look:

Colours: Dark navy (#1a1a2e) for title block, blue (#0f3460) for section headers, red (#e94560) for internal issues, green (#27ae60) for on-track, orange (#f39c12) for review-needed, blue (#2980b9) for other statuses
Fonts: Helvetica family (Bold for headers, Regular for body)
Tables: Dark header row with white text, alternating row backgrounds, thin grid lines (#bdc3c7), compact padding (2-3pt)
Page: A4, 18mm left/right margins, header line with "Helloprint | Delay List Step 3 Report | [date]", footer with "Confidential - Helloprint Operations" and page number
Email blocks: Separated by horizontal rules (blue #2980b9), not wrapped in a single table cell (large supplier email blocks with many orders must be able to split across pages)

Implementation Note

Do NOT wrap email blocks in a single-cell Table flowable — suppliers with many orders (e.g. Yurchak with 40+ orders) will overflow a single page and cause a LayoutError. Instead, use individual flowables (Paragraph, Table, Spacer) separated by HRFlowable dividers. This allows reportlab to split content naturally across page breaks.

MCP & API Integration Points

Action	Integration	Template/Endpoint
Fetch delay list	traffic-mcp	get-delay-list workflow
Snooze order	traffic-mcp	snooze-orders workflow

Before processing begins, verify all required MCP servers and API endpoints are accessible. If any integration is unavailable, flag ALL affected orders for MANUAL_REVIEW rather than failing silently.

Configuration

These defaults can be overridden by the operator at the start of each run:

snooze_default_hours: 12
max_batch_size: 100
confidence_threshold: 99       # Percentage — below this → MANUAL_REVIEW
customer_notify_after_days: 2  # Notify customer after X business days delayed
supplier_email_after_days: 1   # Email supplier after X days with no movement
auto_snooze_carriers:
  - UPS-UPS_STANDARD
  - UPS-UPS_SAVER
  - DPDINT-STANDARD_UK
  - DPDINT-STANDARD
supplier_specific_processes:
  probo: on_hold
  flyeralarm: on_hold
  masterprint: completed

Edge Cases & Known Issues

Incorrect delay day calculation — The system sometimes shows different delay counts for orders with the same dispatch date. Always recalculate: business days between Target Dispatch Date and today.
Sales price shows full order, not order-line — The delay list may show full order price. Be aware when assessing value thresholds.
False delays from Probo — Orders shipped together across multiple order lines trigger false delays. When Probo processes activate, always check if lines were shipped together before acting.
Duplicate supplier emails — The bundling rule is critical. Always deduplicate and group before sending. Check if a supplier was already emailed today.
Tracking lag vs. genuine delay — Packaged orders with tracking from approved carriers/suppliers are most often tracking lag. Auto-snooze handles this, but if an order reappears after multiple snoozes, escalate to MANUAL_REVIEW.
Orders assigned to team members — If an order has an Assigned value, it means someone is already working on it. Consider skipping or noting this in the review queue.
Incomplete order evaluation when filtering When filtering the delay list, always feed the raw API response directly into the filter logic — never manually reconstruct or subset the data. After filtering, validate that: Every order with statename = "Your order has been packaged" appears in either the match list or the reject list The count of (matches + rejects) equals the total number of packaged orders in the raw response
The Posterman Exception When the supplier is The Postermen, the carrier field may be any value when validating snooze applicability. All other matching criteria still apply as normal.
Orders from supplier Oakdene Services with a carrier of DPDUK-STANDARD or DPDUK-EXPRESSPAK are eligible for auto-snooze if all other auto-snooze criteria are also met.

Example Run

Operator: "Process today's delay list. No special notes."

Step 1: Fetched delay list via API → 347 delayed orders. 4 records missing data → MANUAL_REVIEW.
Step 2: 89 orders match auto-snooze criteria → Snoozed 12h. Batch 1/1 (89). All succeeded

SUMMARY: 343 processed | 16 manual review | 0 failures
Logs saved: delay_log_2026-02-12.csv, summary_2026-02-12.md

26 KiB Raw Blame History