The Problem: Repetitive Order Status Tickets in a Swiss B2B SaaS Company
Your support team in Switzerland handles 1,200 order and shipment status inquiries per month. Each ticket takes a median of 4.2 hours to first response, and the cost per resolved ticket is EUR 18.50. The root cause is not headcount; it is that 70% of these tickets are repetitive, and the agent must manually check the ERP, the CRM, and the shipping carrier’s portal before drafting a reply. The EU AI Act, which applies to systems serving EU customers, requires that any AI system handling customer communications be classified, documented, and subject to human oversight. You need a workflow that extracts the order number from the email, queries the ERP and shipping API, drafts a status reply, and routes it to a human approver before sending. The 8-week timeline assumes you have API access to your CRM, ERP, and helpdesk, plus a named business owner who can approve scope changes within 48 hours.
Prerequisites: What You Need Before Week 1
Before step 1, you need the following in place: API credentials for your CRM (e.g., Salesforce or HubSpot), your ERP (e.g., SAP or NetSuite), and your helpdesk (e.g., Zendesk or Freshdesk). You need access to the Google Workspace admin console to create a service account with Gmail API and Sheets API scopes. You need a sample of at least 200 historical tickets from the last 90 days, exported as CSV with fields for ticket ID, customer email, order number, first-response timestamp, and resolution timestamp. You need a named business owner in operations who can approve the pilot scope and sign off on the baseline metrics. You need a dedicated AI team of 3-4 people: a technical lead, a product designer, and a data engineer, embedded in your operations department. You need a clear definition of what “first response” means in your context: is it the first human reply, or the first AI-drafted reply that is approved and sent?
Step 1: Capture the Baseline in Week 1
Export 200 historical tickets from your helpdesk as a CSV file. Calculate the median first-response time, the mean cost per resolved ticket, and the error rate (percentage of replies that required correction before sending). Store these numbers in a Google Sheet named baseline_metrics with columns for metric, value, and date. This baseline is your before/after reference. Without it, you cannot prove the automation worked. The data engineer on the dedicated team runs this in week 1, and the business owner signs off on the numbers before the pilot build begins.
Step 2: Build the Extraction and Drafting Pipeline in Weeks 2-3
Build the extraction pipeline that reads the customer email from Gmail via the Gmail API, extracts the order number using a regular expression or a small language model, and queries the ERP and shipping carrier API for the current status. The orchestration layer, built with n8n or Temporal, routes the extracted data to the OpenAI API for drafting a natural-language reply. The reply is stored in a Google Sheet named ai_drafts with columns for ticket ID, draft text, confidence score, and approval status. The human approver sees the draft in a simple web UI or a Gmail label, clicks approve or reject, and the approved reply is sent via the Gmail API. The entire pipeline runs in under 18 ms for the extraction step and under 2 seconds for the draft generation.
Step 3: Run the Pilot on 50 Live Tickets in Weeks 4-5
Run the pipeline on 50 live tickets from the support inbox. The human approver reviews every AI-drafted reply before it is sent. Track three metrics: the percentage of drafts that are approved without correction, the median time from ticket creation to approved reply, and the number of API calls to OpenAI per ticket. If the approval rate is below 70%, the drafting prompt needs tuning. If the median time is above 30 minutes, the orchestration layer has a bottleneck. The data engineer logs every API call, every human intervention, and every error in a Google Sheet named pilot_log. This log is your compliance record under the EU AI Act, and it is also your debugging tool.
Step 4: Roll Out to the Full Inbox in Weeks 6-8
Extend the pipeline to the full support inbox, not just 50 tickets. Add a second workflow for shipment status updates, which uses the same extraction and drafting logic but queries the shipping carrier API instead of the ERP. The orchestration layer now handles two document types: order status and shipment status. The human approval queue is scaled to handle the increased volume. The dedicated team monitors the pilot_log sheet daily for error spikes. If the error rate exceeds 5%, the team pauses the rollout and re-tunes the extraction regex or the drafting prompt. The rollout phase runs for 3 weeks, and the business owner reviews the metrics at the end of week 8.
Common Pitfalls and How to Detect Them
The most common failure is scope creep: stakeholders add new document types or new customer segments mid-pilot, which breaks the 8-week timeline. Detect it by tracking the number of new API integrations requested after week 2. The second is underestimating the human approval queue: if 30% of AI-drafted replies need correction, the approval step becomes a bottleneck. Detect it by measuring the median time from draft creation to approval. The third is API rate limits: OpenAI’s API has per-minute and per-day token limits, and a spike in order status queries can hit them. Detect it by monitoring the 429 error rate in the pilot_log. The fourth is poor baseline data: if you do not capture 200+ historical tickets in week 1, you cannot prove the before/after improvement. Detect it by checking the row count in the baseline_metrics sheet before the pilot build begins.
Leave a Reply