HubSpot Implementation Notes for this Knowledge Base

5.1 Confirmed existing schema (already live — build on this, don't duplicate it)

• hs_ticket_category (Category): Account & Billing (BILLING_ISSUE), Data & Reporting (FEATURE_REQUEST), Device & Hardware, General inquiry (GENERAL_INQUIRY), Installations & Onboarding, Platform & Application (PRODUCT_ISSUE).
• request_type: App Invite, Bug, Other, Report Request (plus the six Category values also appear as options here — worth checking with the team whether request_type and hs_ticket_category are meant to stay in sync or serve different purposes, since they currently overlap).
• Per-category Sub-Category properties: account_billing, data_reports, device_hardware (device type), device_hardware_issue_type (issue type), installations_onboarding, platform_application.
• site_id and sitemetric_site_id (string properties) exist directly on the ticket object, in addition to the Site association — worth confirming with your team which is the source of truth so the chatbot logic in 3.1 references the right one.
• Ticket status/pipeline stages already reflect multiple distinct pipelines: a general request flow (New → Request in Review → Request Processed → Duplicate/Cancelled), a standard support flow (Open → Waiting on Customer/Support → On Hold → Escalated → Closed), and a field-service flow (Waiting on Parts/Vendor → Waiting on Approval → Needs Scheduling → Service Scheduled → Repair in Progress → Pending Verification → Closed/Cancelled) — this last one is clearly meant for Device & Hardware tickets and should be the target pipeline referenced in 2.3/3.3.

5.2 Gaps worth closing

• Device & Hardware has device-type and issue-type as two separate Sub-Category-style properties rather than one combined field — fine as-is, but chatbot logic and any reporting should treat them as a pair (see 2.3), not independently.
• No property currently captures "power/connectivity event preceded this" as a discrete flag — given how often that explains a hardware ticket (2.3), consider adding a boolean or short-text property so this diagnostic step gets logged consistently rather than living only in ticket body text.
• request_type and hs_ticket_category having overlapping values is worth a quick cleanup pass so the AI chatbot isn't given two competing signals for the same classification.

5.3 Structuring this content in HubSpot Knowledge Base

• One KB article per Part 2 subsection (2.1 through 2.6), titled to match the Category/Sub-Category names exactly, so agents and the AI chatbot can map a ticket's properties straight to the matching article.
• Import the 18 existing Solutions articles (App Verbiage, Reports, Mustering/Roll Call, Scanning, SSO, HammerTech Sync, etc.) as their own "Product & Platform" category, separate from the request-type articles.
• Part 3 should be marked internal-only (Article Permission) since it's operating guidance for agents/bot, not customer-facing content.

5.4 Feeding this into an AI chatbot / RAG setup

• Each Part 2 subsection already carries its Category/Sub-Category name in the heading — index on that so a ticket's actual property values retrieve the matching article directly, rather than relying on free-text similarity search.
• Part 3 belongs in the chatbot's system-level instructions (governs behavior) rather than as a document to retrieve conditionally.
• Keep the real ID format examples in the text (NYS8UY2AXC, B0MME5BRD9) so the model recognizes the shape of Site IDs and Worker IDs when parsing new tickets.