Four-Week AI Pilot: Automating Order-Status Data Entry in a UK Medtech Firm

The Problem: Manual Order-Status Data Entry in a Regulated UK Medtech Firm

A 51-200 person UK medtech company handling order and shipment status updates for customer support is drowning in manual data entry. Every time a customer emails or calls about an order, an operator opens the CRM, searches for the order reference, checks the logistics provider’s tracking page, types the status back into the ticket, and logs the interaction. At 12-18 minutes per request and 3-5 percent transcription error rate, this single workflow consumes 15-25 percent of the support team’s capacity. The problem is not the volume alone; it is that the data is unstructured (email bodies, PDF attachments, voice notes) and the regulatory environment (ISO 27001, UK GDPR) means you cannot simply pipe customer emails into a third-party API without a documented risk assessment. The pilot targets this one process, automates the extraction and classification, and ships with a measured before/after baseline that proves the case for rollout.

Prerequisites Before Week 1

Before the dedicated AI team begins the four-week pilot, you need the following in place:

• One named process owner from the customer support team who can answer questions about the current workflow and approve the pilot scope.
• Access to historical documents: at least 200-500 examples of customer emails, PDFs, or spreadsheets containing order and shipment status requests, exported from Google Workspace or the CRM.
• CRM API credentials with read/write permissions for the order and ticket objects, scoped to the pilot’s data set.
• Google Workspace API access: Gmail API and Google Drive API scopes for the pilot mailbox, with data residency set to the UK or EU region.
• A GPU server or cloud instance with at least 80 GB of VRAM (e.g., an A100 or H100) for running the open-weight model on-premise, or a confirmed decision to use a cloud GPU for the pilot phase only.
• ISO 27001 documentation access: the client’s current statement of applicability and any existing risk assessments covering customer data handling, so the pilot’s controls align with the existing certification scope.

Step 1: Run the Process Audit and Capture the Baseline

The dedicated AI team maps every manual step in the order-status workflow and captures the baseline metrics. You export 200-500 historical requests from Google Workspace and the CRM, and the team tags each one with cycle time (from email receipt to ticket closure), error type (wrong order reference, missed shipment detail, incorrect status), and number of human touches. The output is a one-page scorecard: for a typical UK medtech firm, the baseline shows 14 minutes average cycle time, 4.2 percent error rate, and 3.1 human touches per request. This scorecard becomes the denominator for the before/after report and the justification for the pilot’s scope. The team also identifies which fields in the extracted data touch money, health data, or contracts, because those fields will require human-in-the-loop approval in the next step.

Step 2: Select and Fine-Tune the Open-Weight Model On-Premise

The team selects an open-weight model that fits the client’s GPU and data constraints. For a UK medtech firm where patient identifiers and order details cannot leave the building, the default is Llama 3 70B or Mistral 8x7B running on the client’s on-premise A100 server. The model is fine-tuned on the 200-500 historical documents from Step 1, using a supervised fine-tuning (SFT) dataset where each example pairs the raw email or PDF with the correctly extracted fields (order reference, shipment ID, status, date, customer name). The fine-tuning runs for 2-3 epochs on the client’s GPU, taking 4-8 hours. The team evaluates the fine-tuned model on a held-out set of 50 documents, targeting a field-level accuracy of 95 percent or higher before moving to integration. If accuracy falls below 95 percent, the team iterates on the SFT dataset or switches to a larger model variant.

Step 3: Build the Google Workspace and CRM Integration

The pipeline connects to Google Workspace through the Gmail API and Google Drive API. Incoming emails to the pilot mailbox trigger a push notification; the pipeline fetches the message body and any attached PDFs or spreadsheets, passes them to the on-premise inference endpoint, and receives structured JSON output containing the extracted fields. The pipeline then calls the CRM’s REST API to look up the order by reference, pulls the current shipment status from the logistics provider’s API (DHL, DPD, or the 3PL system), and merges the two data sets. The output is a draft customer-facing update and a structured record for the CRM. All API calls are logged with timestamps, request IDs, and data classification tags, feeding directly into the client’s ISO 27001 audit trail. The integration uses the client’s existing service accounts, not new credentials, to minimize the attack surface.

Step 4: Configure the Human-in-the-Loop Approval Gate

The approval interface is a simple web dashboard where the support operator sees a diff view: the source document on the left, the model’s extracted fields on the right, and a highlight on any field classified as touching money, health data, or a contract. The operator can approve, edit, or reject each field. In practice, 70-85 percent of routine order-status updates pass without human intervention because the model’s confidence score exceeds the threshold (typically 0.92) and no sensitive fields are present. The remaining 15-30 percent route to the approval queue with a 4-hour SLA. The queue is monitored by the process owner, and any rejection is logged with a reason code that feeds back into the SFT dataset for the next model iteration. This loop ensures the model improves with each week of live operation.

Step 5: Run the Pilot and Produce the Before/After Report

The pilot runs on a controlled sample of 50-100 live requests over two weeks. The measurement harness captures the same metrics as the baseline: cycle time, error rate, and human touches per request. The team compares the pilot results against the Step 1 scorecard and produces a before/after report. A typical result for a UK medtech firm is a 65 percent reduction in cycle time (from 14 minutes to 5 minutes) and a 50 percent drop in transcription errors (from 4.2 percent to 2.1 percent). The report also documents the ISO 27001 controls in place: on-premise data residency, access controls on the inference server, audit logging, and the human-in-the-loop gate for sensitive fields. This report becomes the business case for rollout to additional workflows, such as invoice processing or document extraction for clinical trial records.