Make scenario development services

How a development engagement runs

1. 01

   Discovery

   Process, exceptions, volumes.

   Output: Requirements

2. 02

   Diagram

   Routes, splits, joins, failures.

   Output: Approved diagram

3. 03

   Build

   Section by section.

   Output: Draft scenario

4. 04

   Testing

   Every route and failure case.

   Output: Test evidence

5. 05

   Handover

   Docs, blueprints, training.

   Output: Handover pack

A diagram before building

For complex scenarios, a simple diagram showing routes, conditions, splits and what happens on failure lets you check the logic before build time is spent. It also becomes part of the documentation.

Who does what

Warning signs

• No fallback routes

  Unmatched bundles disappear.

• Iterators without operation estimates

  Costs may balloon.

• No duplicate protection

  Retries create double records.

• Built in the provider's organisation

  Hard to take over.

Test evidence

Ask for runs showing each route taken, an unmatched bundle caught by the fallback, a retried run that did not duplicate records and a simulated failure triggering an alert. Make's run history makes this easy to show.

Example: comparing two proposals

What you should receive

Support

Complex scenarios need occasional changes as processes and apps evolve. Ask about support, response times and how changes are recorded. Ask for a short change log whenever the scenario is modified.

Ownership

Scenarios should live in your Make organisation, connections should use your business accounts and blueprints should be exported for safekeeping.

Briefing the developer

Describe the process step by step, every exception staff handle today, volumes, the apps involved and who should be alerted when something fails. Include examples of real records for each exception.

Discovery of exceptions

The provider should spend time with the people who run the process to uncover every exception: partial shipments, refunds, missing data, customers on special terms, items that need manual approval. These exceptions decide most of the design and testing effort, and missing them is the most common reason complex scenarios fail after launch. Expect detailed questions, and be wary of a provider that quotes without asking them.

Operation estimates

Ask for an estimate of operations per typical run and per large run, since iterators can multiply module runs. The provider should explain where design choices, such as aggregating earlier or filtering items before costly modules, reduce the estimate. This helps you choose a plan and spot designs that will be expensive to run.

Error handling design

Ask which modules have error handlers, what each does on failure, how partial failures across several systems are handled and who receives alerts. For scenarios that write to finance or customer systems, ask how the provider prevents half-completed runs leaving data inconsistent.

Duplicate protection

Ask how the scenario avoids creating records twice when it is retried or a webhook arrives twice, for example by checking for existing records or keeping processed references in a data store.

What to agree

Agree the scope of routes and exceptions, acceptance tests, ownership of scenarios and blueprints, data processing terms, support and how changes are priced.

One scenario or several

Ask whether the provider plans one large scenario or several smaller ones linked together, and why. Smaller scenarios are easier to test and change; one scenario has fewer pieces to monitor. A good provider explains the trade-off for your team.

Training

Ask for a walk-through of the finished scenario: how to read run history, what each route does, how to pause it and what to do when an alert arrives. Complex scenarios need someone on your side who understands them at a basic level.