How to Build a MAP Enforcement Workflow

Enforcement is the part of a MAP program that reaches outside the brand. Everything before it — monitoring, review, evidence — is internal; a notice lands in a third party's inbox with the brand's name on it and may be quoted back in a dispute. The workflow that produces it therefore needs to be slower and better guarded than the workflow that produces a finding, and it needs to keep a person in charge of every step that has a consequence.

This article lays out a workflow that does that, in seven steps, with the control that belongs at each one. It is the workflow MapProtector implements; the MAP Enforcement Workflow Guide is the longer reference.

Before the workflow starts

Enforcement begins from a confirmed finding, not from an observation. A person has looked at the below-floor price, the seller's standing and the policy, and recorded that the brand considers the price below its policy. Anything upstream of that decision — the scan, the measurement, the queue — is monitoring, and a notice must never be generated from it directly. If your workflow can produce a notice from an observation without a person confirming it, start there.

Three things also need to exist before the first notice can be prepared: a template for the words, a verified sender address the notice will leave from, and a record of how the seller can be reached. None of these is a detail; each is a blocker, and a workflow that lets a notice proceed without one produces a notice nobody can send or, worse, one that goes to a guessed address.

Step 1 — Confirm, with a reason

The confirmation is the brand's statement, in its own records, that a seller's price was below its policy. It is made by someone with the authority to make it — a Compliance Manager or a Brand Admin, not whoever is working the queue — and it opens or extends a case: the persistent record of that seller on that product.

Dismissals carry a reason from a closed list. That list is how the program learns about itself; see How Brands Monitor MAP Violations on Amazon.

Step 2 — Prove

A confirmed finding needs a sealed record before it can be cited. The evidence package is assembled from the observation, the evaluation, the policy version and the confirmation, fingerprinted, and sealed by a brand administrator. Only a sealed package can carry a notice; an unsealed one is a blocker.

The sequence matters: seal before preparing, not after. A notice prepared against an unsealed package is a notice whose evidence can still change. What Evidence Should You Capture for a MAP Violation? covers what the package needs.

Step 3 — Prepare

A person chooses to act on the case. That choice starts the brand's escalation sequence for the current breach period and drafts its first stage: the template rendered with the seller, the product, the observed price, the MAP, the gap, the policy and the case and evidence references. The rendered document — subject, body, recipient, sender — is frozen as a snapshot and hashed. Preparing sends nothing; it puts a document in front of an approver.

Step 4 — Gate

Before the draft can be approved, every condition that would make sending wrong is checked, and the whole list is shown. A notice blocked by three things is not unblocked by fixing one. The conditions group naturally:

The gate runs three times: when the draft is prepared, when it is approved, and again on the send path inside the same transaction that would release the message. A notice that passed yesterday and fails today goes back to review with the reason, not to the seller.

Step 5 — Approve

An approval is a person's answer to a specific question: this seller, this price, this policy, this evidence, this text — send it? It is given by a brand administrator with a fresh second factor and an explicit attestation, and it is a signature over the exact bytes of the snapshot.

Because it answers a specific question, it lapses when the question changes. If the document is re-rendered, the policy version changes, the recipient changes, the evidence is superseded, the case cures, the sender loses verification, or a hold is placed, the approval is invalid and the notice returns to review. This is the control that prevents the classic failure: approved on Tuesday, sent on Thursday, to a seller who corrected their price on Wednesday.

Step 6 — Send, from your own address

The approved notice is released by a brand administrator — a second act, with a second fresh factor, at a second instant. It leaves from a sender identity the brand configured and verified, never from the monitoring vendor's address: the seller should read a notice from the brand about the brand's policy, replies should arrive at the brand's reply-to, and complaints should land on the brand's sending reputation rather than on the one that carries its password resets.

On the send path the notice is claimed so no second process can take it; the gate is re-run; the approval is re-validated against current state; the recipient is re-checked against the suppression list; a delivery record with a unique key is opened; and only then is the mail provider called. One approved notice sends once, whatever a worker believes.

Three delivery states, not two: sent (the provider accepted the message), delivered (the provider reported the recipient's server accepted it), and delivery unknown (the provider did not answer in time). The third is never retried automatically, because the wrong way to resolve a doubt is to send a second copy.

Step 7 — Verify, from observation

The listing stays on its schedule. The breach period closes as cured only when enough fresh, fully covered observations show the price back at the floor — never on a hidden price, a disappearance, or a reply that says "we have fixed it". A reply is recorded as what the seller said and pauses the sequence for a person to read; it does not change the seller's standing and it does not cure anything.

If the price returns below the floor later, a new period opens on the same case, numbered, with the previous one intact as history. Whether that relapse restarts the sequence, and at which stage, is a person's decision when they choose to prepare again. How to Track Repeat MAP Violations covers the recurrence side.

The shape of the whole thing

observation → candidate → CONFIRM (person) → case
           → PROVE (seal, admin) → PREPARE (person)
           → gate → APPROVE (admin, fresh factor)
           → gate → SEND (admin, fresh factor) → delivery
           → observe → cure or recurrence

Every arrow is a place the workflow can stop, and most of them are places a person stops it. Nothing in it sends because a clock elapsed: when a sequence stage's wait runs out, the stage is re-evaluated — the gate runs, a draft is prepared, an approver is asked — and never sent.

Two things a workflow should refuse

Automatic escalation. "Second notice seven days after the first" is a schedule, not an authorization. The schedule decides when to ask; a person decides whether to send.

Managed sending in the vendor's name. A notice that leaves from the monitoring vendor's address misattributes the policy, misroutes the reply and mixes the vendor's reputation with the brand's. If a vendor offers to send on your behalf from its own domain, ask where the replies go.

The MAP Enforcement Workflow Guide turns the seven steps into a runbook, with the roles, the checks and the wording to decide before the first notice goes.