AI delivery fraud control is most useful when it separates facts from judgment. Rules can confirm whether a delivery event belongs to one eligible CRM record, while AI can assess limited visual questions such as whether a customer and motorcycle appear together. A named reviewer then handles unclear evidence instead of forcing every image into a valid-or-invalid answer.
This guide presents an implementation pattern for delivery-photo evidence review. It is not an automated lending decision or a general fraud-detection system. The proposed policy uses three outcomes: VALID, INVALID, and REVIEW. Keep CRM eligibility and other authoritative business facts in deterministic checks; use visual AI only for bounded interpretation.
The workflow below is deliberately framed as a design recommendation. The Zapier customer story discussed here reports a Galgo process, but it does not publish a reusable Zap, complete field mapping, prompt, review interface, or output schema.
The operating principle: automate routine checks, preserve human judgment
Exception-based review reserves human attention for submissions that fail a rule, produce an ambiguous visual result, or require policy judgment. Its purpose is not merely to inspect more images quickly. A well-designed process also applies policy consistently, preserves the reason for each decision, and assigns ownership when automation cannot safely proceed.
Automate a clear case; assign an unclear case to a named human owner. Missing data is an operational exception, never proof of a valid delivery.
VALID means the required deterministic and visual checks passed. INVALID means a documented rejection condition is clear. REVIEW means the evidence, output, or policy context is uncertain or incomplete. Infrastructure failures such as an unavailable image or failed CRM lookup should have their own operational route rather than being labelled as fraud.
What the Galgo case study reports, and what it does not establish
A Zapier customer story describes Galgo as a company that finances motorcycles and reports its use of delivery-photo review. The story reports more than 3,000 photos per month, roughly three minutes of manual review per image, and approximately 150 hours of monthly review. It also reports that invalid evidence fell from about 8% to below 2%, while fewer than 60 photos per month required manual attention.
Those figures are claims from a customer story, not independently audited results or a forecast for another organization. The article does not publish the underlying sample, denominator definition, measurement method, confidence interval, or causal analysis. Ignacio Piñeiro is quoted as estimating at least tens of thousands of dollars in avoided first-payment defaults, but the story does not provide the calculation or evidence needed to treat that estimate as measured return on investment.
The story describes a process involving HubSpot, AI by Zapier, Google Sheets, and Slack: an agency logs a delivery, the associated deal and image are retrieved, AI screens the evidence, a decision is logged, and exceptions are alerted for human attention. It says the reported policy accepted watermarks and rejected stock photos and signed documents. Those are reported policy choices, not built-in AI by Zapier rules.
Zapier’s story says the workflow used GPT-5-mini. It does not provide a configuration export or enough detail to reproduce the historical model setup. Treat the case as an operating-model example. Confirm current model availability, account configuration, permissions, limits, and image requirements in the production account before building.
Design the workflow around the evidence event
Use one delivery-evidence submission, or one version of a submission, as the unit of work. A deal may have multiple photos, a photo may be replaced, and a model may run more than once. These are different records and activities, not interchangeable counts.
A proposed evidence event should carry only the context needed to assess and audit the image:
- Identity:
evidence_event_id,delivery_event_id, andevidence_version. - CRM context:
crm_object_idand, where needed,expected_vehicle_idor vehicle class. - Submission details:
image_reference,submitted_at,submitting_agency_id, andsource_system. - Policy context:
policy_version, with model executions and human decisions stored separately.
A proposed event key is source_system + delivery_event_id + evidence_version. Create a separate model_run_id for every AI execution, including retries and secondary classification calls. Create a separate review_id for each human decision. Use internal customer references where possible instead of sending unnecessary personal data to the model or notification channels.
Keep the evidence event as the submission-level record. Store model runs and reviewer actions as records linked to that event. Calculate an invalid rate from event-level outcomes and a stated denominator. Do not count retries as extra photos or put a monthly aggregate into an individual image record.
Zapier’s HubSpot integration reference lists CRM search and update capabilities, but it does not define a safe event schema or prove how Galgo mapped its records. Teams designing the identity and update gate can also review HubSpot systems support.
Separate deterministic checks from visual AI judgment
Use a rule when an authoritative system can answer the question reliably. Examples include whether the event exists, whether the CRM lookup returned one record, whether the deal is eligible, whether the file is an allowed image type, and whether the evidence version was already processed. These checks are easier to test and audit than asking a model to infer the same facts.
Use AI for bounded visual questions such as whether a person and a vehicle appear together, whether the image looks like a document rather than a delivery photo, or whether the image is too unclear to judge. Do not ask the model to infer borrower eligibility or CRM facts available from the system of record. An inaccessible image is an operational failure, not evidence of a valid delivery.
AI by Zapier documentation describes configurable prompts and named output fields, including image analysis when the image is accessible to the action. It recommends a direct file link rather than a share link. A private, expiring, permission-gated, or non-downloadable URL may fail, so confirm the access path and file constraints in the connected account.
The case study’s watermark, stock-photo, and signed-document rules should be implemented as explicit policy decisions and tested against representative examples. They should not be presented as vendor defaults. A vehicle identifier or eligibility status that already exists in CRM should come from CRM, not from visual inference.
Specify a structured result and an explicit review gate
Configure named output fields rather than relying on a free-text paragraph. The following is an illustrative contract for the proposed workflow, not Galgo’s published schema or a Zapier template:
{
"evidence_event_id": "delivery-app:DEL-12345:V2",
"model_run_id": "delivery-app:DEL-12345:V2:RUN-02",
"verdict": "REVIEW",
"reason_code": "IMAGE_UNCLEAR",
"reason_text": "The image does not clearly show the required evidence.",
"requires_human_review": true,
"policy_version": "delivery-policy-2026-11-01"
}Use enumerated verdicts VALID, INVALID, and REVIEW. A controlled reason list might include NO_PERSON, NO_VEHICLE, DOCUMENT_ONLY, STOCK_IMAGE_SUSPECTED, VEHICLE_MISMATCH, IMAGE_UNCLEAR, and OTHER.
Before any consequential CRM status change, validate that required fields exist, the verdict and reason are allowed, and the returned event ID matches the triggering event. Require a controlled reason code for INVALID. Treat malformed output, ambiguous evidence, image-access errors, and any meaningful low-confidence signal exposed by the configured model as REVIEW or an operational exception, never as VALID.
A forced binary answer turns uncertainty into an apparently final decision. Validate the event identity and structured output first, then give ambiguous evidence, malformed output, and unavailable images a safe REVIEW or operational destination.
Route decisions, preserve provenance, and assign ownership
For VALID, record the result and update only the verified evidence status if policy permits automatic progression. For INVALID, retain the reason and source evidence reference, then notify the fraud or operations owner. For REVIEW, assign a named reviewer or queue with a due time. Preserve the AI result and store the human decision separately.
Route CRM_LOOKUP_FAILED, IMAGE_UNAVAILABLE, and AI_TIMEOUT to an operational failure queue. These indicate a workflow or provider problem, not a fraud finding. A reviewer override must not erase the original model verdict, reason, run ID, or policy version.
Zapier documents Filter and Paths for conditional routing and supports review states in which a workflow can pause for human action. The Galgo story does not say whether its reviewers used Zapier’s Human in the Loop feature, Slack, or a custom interface. Keep the durable audit record in the designated system of record; use Slack for restricted alerts, not as the sole record of a decision.
For each reviewable event, preserve the event ID, CRM object ID, evidence version or storage reference, submission time, model and policy version, model run ID, verdict, reason, reviewer ID, human decision, and timestamps. Limit customer details in notifications and restrict access to images and audit data under the organization’s privacy, retention, and security requirements.
For teams assessing the boundary between bounded AI and accountable workflow ownership, AI agents and workflow design is a relevant implementation resource.
Prevent duplicate decisions and protect the image path
Use an idempotency key based on source_system, delivery_event_id, and evidence_version. Do not key only on a deal ID, filename, or month. One deal may have replacement evidence, and filenames can be reused.
Zapier’s trigger deduplication compares incoming unique IDs within an individual Zap. It does not guarantee unique destination writes across multiple Zaps or concurrent runs. Replay can also repeat a downstream action. A lookup-then-create sequence can race when two runs both check before either writes.
When concurrency or financial impact matters, enforce uniqueness in a durable database and use an atomic upsert or insert-on-conflict operation. Make CRM updates and audit writes idempotent so a retry for the same evidence version cannot create a second decision or overwrite a later human decision. This is an implementation recommendation, not a database guarantee supplied by the cited Zapier integration.
AI by Zapier image analysis requires an image accessible to the action. Resolve restricted images through an approved access path, and treat an expired or non-downloadable link as an operational exception. Check task allowance, app rate limits, burst behaviour, and image constraints against the connected production accounts before rollout.
- Submit the same evidence version concurrently. Pass only when one durable event record and one final status exist.
- Replay after a successful write. Pass when the existing event is recognized and no duplicate audit row or CRM transition appears.
- Use an expired image link. Pass when the event enters the image-failure route and cannot become VALID.
- Return zero and multiple CRM matches. Pass when both cases stop before the consequential update and reach the operations queue.
Measure review performance at the correct grain
Calculate submission-level metrics from evidence events, with the period and denominator stated:
- Review rate: evidence events sent to human review divided by submitted evidence events.
- Invalid rate: invalid evidence events divided by evaluated evidence events under a consistent policy.
- Image failure rate: inaccessible or unsupported images divided by submitted evidence events.
- Median review age: time from exception creation to human resolution.
Track process diagnostics separately: retry rate, malformed-output rate, duplicate-write attempts, and human override rate. A second model call or replay is a model run, not another delivery submission. Monitor prompt and policy versions over time, and tune them manually against observed failure modes. Do not describe the model as learning autonomously from reviewer actions.
Use the Galgo figures as attributed case-study context, not as a predicted return. A team estimating financial impact would need its own definitions, observation periods, denominators, first-payment-default definition, exposure assumptions, and counterfactual analysis.
Implementation boundaries and source notes
The AI by Zapier documentation supports configurable output fields and image analysis from an accessible image link. Zapier also documents conditional routing, human-review states, trigger deduplication, replay, and workflow limits. These sources establish component capabilities, not a complete delivery-fraud template.
The case study does not publish Galgo’s exact prompt, CRM object schema, field mappings, spreadsheet columns, Slack permissions, review interface, retention policy, or measurement method. Any production workflow involving customer images, identity data, or lending-related decisions needs separate privacy, security, retention, and regulatory review. The architecture described here is a practical starting point for that assessment, not evidence that a particular implementation will reproduce the reported results.