HC Grillz sells a highly personal, made-to-order product. That makes customer support a trust workflow, not a place for unsupervised automation. RECAST built an operating layer that can assemble order context and prepare action while keeping consequential sends and provider writes under named human control.
Evidence at publication: inspected passes covered Shopify reads, fulfillment-sheet reads and order lookup, guarded support review/edit behavior, saved Google Ads reporting, partial Klaviyo reporting and controlled synthetic Gorgias write tests. Real-channel and several provider lanes remain gated, so the public state is live and supervised.
The company
Tyler runs HC Grillz from Australia while expanding into the United States and Canada. A typical order passes through several physical states: the customer orders, a mold kit ships, the customer returns the mold, the Australian team produces the grillz and the finished product moves toward delivery.
That journey creates understandable support questions. Answering one may require the current Shopify order, the correct row or tab in a fulfillment sheet and knowledge of what the production state means for the customer.
The constraint
The information needed for a good reply existed, but it lived across systems. A support operator had to check the commerce record, interpret fulfillment state and draft language appropriate to a high-consideration custom purchase.
Tyler's hesitation was rational. A system that hallucinates an order status, writes to the wrong provider or sends an unreviewed message creates more than an automation error; it creates a brand and accountability problem.
Why existing tools were not enough
Shopify could show the order. Google Sheets could show fulfillment progress. Gorgias could hold the support conversation. None alone guaranteed that those sources had been reconciled before a response was prepared.
The missing layer needed read-path proof, source-specific status mapping, review/edit gates, action journals and a clear difference between synthetic provider QA and normal production use. A polished dashboard was useful only if it showed what was proven and what remained locked.
Transformation map
Before
Customer question -> Shopify check -> fulfillment Sheet search -> production interpretation -> manual reply -> fragmented record
After
Gorgias queue -> Shopify + Sheet evidence -> Atlas support review -> Shelley approval/edit -> controlled send or hold -> action journal
The final action remains supervised. The system earns autonomy route by route instead of assuming it globally.
One workflow, end to end
- Input: A support question enters the Gorgias queue for order or fulfillment status.
- Evidence retrieval: Atlas checks the Shopify read path and the relevant fulfillment-sheet route rather than relying on conversational memory.
- Status assembly: The workflow combines order information with the applicable mold-kit or production state.
- Draft: A response is prepared under the support SOP and explicit no-send rules.
- Human gate: Shelley reviews, edits or rejects the draft before any real customer-facing action.
- Controlled action: Only an approved, proven provider route may send or close; otherwise the item remains prepared for manual handling.
- Record: The action journal and provider tracker preserve what data, account, approver and smoke test supported the action.
This route describes the supervised operating design. The retained source does not establish that every real support channel is fully activated.
What changed
- Built: Atlas owner mode, daily brief, support triage, order-status lookup, reply drafting, marketing snapshots and outreach preparation.
- Connected and read-tested: Shopify, fulfillment Google Sheets, saved Google Ads exports and a partial Klaviyo reporting path.
- Governed: Shelley support approval, review/edit guards, explicit no-send/no-write rules and encrypted credential handling.
- Provider-tested: Controlled synthetic Gorgias assignment/readback and send-close QA were completed.
- Verified live under supervision: The operating surface and proven read lanes can support internal review; unrestricted customer automation is not claimed.
- Remaining: Real-channel support validation, some provider lanes, Meta live reporting, KPI ledger read/writeback, deeper Klaviyo proof and exact fulfillment status mapping.
- Financial result reported by client: None retained.
Proof
- Commerce receipt: Shopify read and dashboard routes passed inspection.
- Fulfillment receipt: Sheet read, order lookup and tab-list behavior passed in the proof lane.
- Support receipt: Review/edit guards and Atlas no-write chat behavior were tested.
- Provider QA receipt: Synthetic Gorgias assignment/readback and controlled send-close tests passed.
- Reporting receipt: Saved Google Ads export analytics and a partial Klaviyo read were available.
- Boundary: Synthetic writes are provider proof, not evidence of routine live customer sends. Meta, KPI-ledger and some status lanes remain open.
Technology - revealed last
The Tyler-owned VPS hosts OpenClaw and the Atlas command center. Provider paths cover Shopify, Gorgias, Google Workspace and Sheets, Google Ads saved-export analytics and Klaviyo reporting. An encrypted API vault, capability routes, action journals, proof trackers and combined status gates make the state of each action inspectable. The control system is deliberately as important as the model route.
Client quote
No source-backed verbatim client quote is published for this case. Tyler's documented caution informs the control architecture but is not converted into testimonial copy.
Next transformation
See how Plutify keeps QuickBooks read-only while giving clients a live CFO review surface. Both systems create leverage by proving reads before unlocking consequential writes.
Get your AI blueprint
If every customer reply depends on reconstructing state across commerce, fulfillment and support tools, the first step is not autonomous sending. It is a proven evidence path. Book a free AI audit to map yours.
Source record
OPENCLAW-DEEP-CLIENT-CASE-STUDIES.pdf, page 25.RECAST_CASE_STUDIES_2026_UPDATED.pdf, page 21, documentRA-CASES-001, version 2.0.RECAST_WEBSITE_MASTER_BLUEPRINT.md, sections 10.5, 11 and 58.