Clearing 12,000 Support Tickets Before the London Shift

The support queue waiting at midnight

Imagine a support team in London arriving at 08:00 to find 12,000 tickets ready for review. Each ticket needs a topic, a short summary, and a flag indicating whether someone should investigate further. The work can happen overnight because nobody needs each result immediately.

That is the idea behind an overnight batch job: collect a set of tasks, process them without someone watching every request, and deliver the results before a deadline. For this example, the proposed split assigns the initial pass to DeepSeek V4 Flash and selected reviews to DeepSeek V4 Pro. Treat those assignments as a starting hypothesis to test on your tickets.

Two queues with different assignments

Start with one queue containing every ticket. Ask the first model to choose from a fixed list of topics, write a two-sentence summary, and identify evidence that the ticket needs review. Keep the instructions identical across records so the results are easier to compare.

Build a second queue from explicit rules. A ticket could enter it because it mentions a disputed refund, contains conflicting dates, or fails a required output check. Give the reviewing model the original ticket, the initial answer, and the reason for escalation.

This second pass should have a specific assignment: resolve the conflicting dates, reassess the category, or explain which information is missing. Asking it merely to improve the answer makes success difficult to measure. Keep unresolved cases visible for the morning team.

A small rehearsal before the full run

Before scheduling 12,000 records, select perhaps 100 tickets covering ordinary requests, long conversations, and awkward exceptions. Have a person label the expected topics and note the details each summary must preserve.

Run the proposed split against that sample. Compare its results with sending the same sample through the reviewing model directly. Measure acceptable answers, total spend, elapsed time, and how many tickets require escalation. Use those observations to choose the routing rules.

A model's statement that it feels confident should not decide the route alone. Prefer checks you can inspect: an allowed category, a required field, a quoted date, or a business rule triggered by the ticket text.

One record that survives a restart

Give every ticket a stable identifier and store progress outside the process running the job. A practical record should include:

• The ticket identifier and a reference to its source text.
• The prompt version and the requested model identifier.
• The current stage: pending, initial pass complete, review pending, or finished.
• The saved response, validation result, and escalation reason.
• Attempt count, timestamps, and usage information when returned.

After an interruption, select unfinished stages rather than submitting the entire collection again. Save each completed result before marking its stage finished. Use the ticket identifier when writing the final output so a repeated attempt updates the same record.

The deadline and spending rules

Set an explicit timezone for the 08:00 deadline. Reserve time before it for validation, exporting results, and handling failures. Start with a modest number of simultaneous requests, then adjust using observed completion times and the limits of your account.

Define a maximum spend and a bounded retry policy. For temporary failures, retry after increasing delays; after the final attempt, record the failure for inspection. If the review queue grows beyond the remaining time or budget, flag those tickets as pending human review instead of silently treating them as complete.

Schedule the work overnight for the team's deadline. Do not assume the time of day brings a discount or that your relay offers a dedicated batch endpoint; verify those details before budgeting or implementing either feature.

The first morning report

For a first implementation, I recommend RelayVano as a pay-as-you-go relay compatible with an OpenAI-compatible SDK. Sign up, confirm the available model identifiers and account limits, and run the rehearsal before scheduling the full queue.

Deliver a morning report showing completed tickets, escalations, validation failures, unresolved records, and recorded spend. Include a small sample for human inspection. The first useful milestone is a dependable report with visible exceptions, giving the team enough evidence to decide whether tomorrow's run should process more work.