What Just Eat Spain Checks Before a Restaurant Goes Live

A signed contract is an important event. It is not, by itself, evidence that a partner can operate.

This distinction is easy to lose in an onboarding workflow. Sales marks a deal as signed, an automation sends a message to Operations, and a task appears for Logistics. The dashboard looks active. Yet the partner may still lack a completed listing, a delivery setup, an assigned owner, or the practical confirmation needed to go live. A message proves that information moved. It does not prove that the preceding business stage is complete.

That is the useful architectural lesson in Zapier’s published customer story about Just Eat Spain. The case describes an onboarding process involving five teams. Before the redesign, teams worked from separate views of the same partner record, searched Salesforce dashboards, checked status manually, and copied information between systems. An incomplete case could also travel too far through the process before somebody caught it.

The published case is a vendor customer story, not an independent audit. Zapier reports onboarding-time reductions, but its public page does not provide the measurement period, partner population, exception denominator, or attribution method needed to treat those figures as a general benchmark. The important evidence here is the process design: it connects progression to conditions and retains a human readiness decision.

The queue is not the process

Many onboarding systems are built as a chain of notifications: Sales notifies Listing; Listing notifies Logistics; Logistics notifies an account manager. This is a queue-management pattern. It may distribute work faster, but it has a structural weakness: every downstream team must infer whether the work is actually ready.

That inference creates familiar waste. People reopen records to look for missing fields. They ask upstream teams for clarification. They rebuild context from messages and dashboards. Or, worse, they complete their local task because it was assigned, while a prerequisite elsewhere remains unresolved. The process appears to advance even though the partner is not becoming more ready to operate.

A stronger design makes the business state explicit. “Signed” means the commercial agreement is complete. “Listing complete” means the listing work has met its defined completion condition. “Logistics prepared” means the operational preparation required for the relevant partner has been recorded. “Ready for review” means the required prior states are present—not merely that tasks were sent. Each state needs an owner, a completion rule, and a durable place to record it against one shared partner identifier.

Notifications still have a role. They tell a person that work is waiting. They must not be the evidence that makes later work safe to start.

Route context, then stop on missing state

In the Just Eat Spain case, the workflow begins when a seller marks a partner as signed in Salesforce. It routes work through listing creation and delivery or logistics preparation, then assigns an account manager based on location and partner type. This is more than a linear relay: routing uses attributes of the partner record to place work with the relevant people.

The more consequential feature is what happens when the record is incomplete. The case says targeted notifications are sent to the responsible people and the process pauses until the issue is corrected. It does not push incomplete information toward launch simply because an earlier event occurred.

That pause changes the operating question. Instead of asking, “Did the workflow run?”, a process owner can ask, “Which completion condition is missing, who owns it, and what state will permit re-entry?” This is a manageable exception queue, not a vague collection of stalled tasks.

Zapier’s own documentation describes Paths as conditional routing and Filters as a way to stop later actions when conditions are not met. It also warns that overlapping Path conditions should be mutually exclusive. For an implementation team, this is not a minor configuration detail. If two routes can match the same record, the process can create conflicting assignments or duplicate downstream activity. The business states and routing rules should therefore be designed together, then tested against realistic incomplete and changed records.

A pause needs a return path

Stopping an incomplete case is safer than advancing it, but stopping is not a complete design. Somebody corrects the missing data or finishes the operational work. The system must then know how the case resumes, from which state, and which later actions have already occurred.

This matters in Zapier specifically because its documentation says replaying a failed run does not necessarily re-evaluate earlier Filter or Paths steps. A repaired record should not be assumed to resume at the correct point automatically. The workflow needs an explicit corrected-state trigger or a controlled re-entry path. It should also prevent a corrected record from creating a second listing request, logistics task, or manager assignment when one already exists.

This is a practical distinction between recovery and repetition. Recovery moves one partner toward a valid operating state. Repetition merely runs familiar automation again and hopes the systems converge.

Keep the final operating decision with a person

The Just Eat Spain case places readiness validation with the account manager. That boundary is well chosen. Automation can carry the signed record, route work by location and partner type, expose missing conditions, and bring the right context to the right team. It cannot establish, merely from a task history, that a restaurant is ready to serve customers in the real world.

People still negotiate and sign the partner, perform the operational setup, resolve exceptions, and validate readiness. This is not a failure of automation. It is the division that makes automation useful: machines move state and context consistently; accountable people make the decisions that require operational judgment.

What to design before connecting the tools

• Define one shared partner identifier across the CRM, operational systems, and task tools.
• Write a completion condition for every handoff. “Task created” is usually not one.
• Name an owner for each exception state and set out how corrected cases re-enter the flow.
• Make routing conditions mutually exclusive where a case must have one destination.
• Use a human readiness checkpoint before activation, with the record and context needed to make that decision.
• Control access to partner data so that routing convenience does not create unnecessary data exposure.

The business benefit is not a claim that every onboarding programme will achieve a particular time reduction. It is more concrete: fewer status searches, less context reconstruction between departments, less time waiting in ambiguous queues, and a lower risk of activating a partner before the necessary work is complete. Those benefits arise when the workflow represents the work honestly.

For leaders responsible for partner, supplier, customer, or employee onboarding, the first review question is simple: does each handoff carry a verified completion state, or only an alert that someone has been notified? If it is the latter, start by mapping the conditions that make the next team’s work genuinely ready. AES can help turn that map into a bounded, testable workflow while retaining the human decisions that belong in the process.

Sources: Zapier customer story, “Just Eat Spain” — https://zapier.com/customer-stories/just-eat-spain ; Zapier documentation, “Add branching logic to Zap workflows with Paths” — https://help.zapier.com/hc/en-us/articles/8496288555917-Add-branching-logic-to-Zap-workflows-with-Paths ; Zapier documentation, “What is replay?” — https://help.zapier.com/hc/en-us/articles/19220226086797-What-is-replay