Turn client intake into a reliable handoff

Your route to a useful result.

1. Map the current process

   Name the trigger, required fields, owner and destination. Start with the four synthetic cases below.

2. Design validation and routing

   Write exact rules before connecting apps. Keep an exception queue for missing fields and unknown categories.

3. Build in a test destination

   Use a test table or sandbox. Connect only the minimum permissions and keep external messages disabled.

4. Test the failure path

   Replay duplicates, missing fields and an unavailable destination. Keep an evidence record for each outcome.

5. Approve and monitor

   Only activate after the owner accepts the results, cost limits and recovery steps. Assign someone to the failure queue.

0 of 5 steps complete

Start with this fictional input.

Synthetic inputs:
A: request_id=demo-001, organization=Harbor Desk, email=owner@example.invalid, request=Review our booking page, category=website
B: same request_id=demo-001, all fields unchanged (duplicate delivery)
C: request_id=demo-002, organization=Maple Studio, email=missing, request=Help with a campaign, category=marketing
D: request_id=demo-003, organization=Test Studio, email=owner@example.invalid, request=New request, category=unknown
Rules: website → web review queue; marketing → campaign review queue; missing email or unknown category → exception queue. Draft only; never email a requester automatically. Use request_id as the duplicate key.

The reusable prompt

Map this intake workflow using the supplied routing rules. Show input validation, duplicate prevention, routing, a draft summary, human approval and failure handling. Give expected results for A–D. A retry must not create a second handoff. Stop for review when an input is missing or a rule does not match. Do not activate a connection or contact anyone.

Check the work against the source.

This is an editorial reference answer. It is not output from a tested vendor.

A → one web review record, draft only.
B → no second record; report duplicate safely.
C → exception queue: missing email; do not guess an address.
D → exception queue: unknown category.
Simulated destination failure → bounded retries with the same request_id, then an exception assigned to an owner. No automatic customer email in this exercise.

• A creates exactly one draft handoff.
• B creates no duplicate.
• C and D go to the exception queue.
• A failed destination creates a visible failure with an owner.
• Retries preserve request_id and never contact customers.