How to estimate Make credits for a real workflow

SOURCE-BASED ANALYSIS · NO HANDS-ON RATING

The short answer

Estimate usage from the number of times each module runs, rather than the number of business events alone. Make documents a default fixed rate of one credit per operation, with exceptions and dynamic consumption for some features. Keep AI usage in a separate line until you know the connection type and the applicable charging rules. This guide builds an illustrative estimate, not a price quote or a measured benchmark.

A worked example: capturing 1,000 enquiries

Suppose a small company expects 1,000 accepted enquiries during a month. Its scenario performs three regular, fixed-rate actions for each enquiry: create a CRM record, create a follow-up activity and send an internal notification. Assume each listed action executes once per enquiry and costs one credit. Those assumptions give a base of 1,000 × 3 = 3,000 credits for the listed actions.

The total is deliberately narrow. It does not include trigger checks, searches, any additional modules, branching, reprocessing or AI calls. Add those from the scenario you actually build. A three-box illustration is not enough evidence that the production scenario has only three chargeable executions.

Why one event can create more work

Make describes bundles as units of data processed by modules. If an enquiry contains four items and downstream actions process each item separately, those actions can run more than once for the original enquiry. Write down the expected item count beside each step. For an order workflow, distinguish one order, its line items and its attachments instead of assuming they are the same unit.

Try a second estimate with a busier input. If two downstream modules each process four items per enquiry, that part of the workflow represents eight module executions per enquiry under the stated assumptions. The useful question is which records flow through each step, not which scenario looks shorter on the canvas.

Separate routine, exceptional and AI consumption

Use three budget lines. The first covers normal successful work. The second covers exception handling and reprocessing: for example, 40 enquiries that need their notification action run once more would add 40 executions to that action under a one-credit assumption. This is a planning example, not a claim that every failure costs a particular amount.

The third line covers AI. Make distinguishes fixed and dynamic consumption and documents different connection arrangements. A custom provider connection can also leave you paying the AI provider separately. Do not put an arbitrary one-credit value against an AI step merely because a neighbouring module uses that rate. Record its documented rule and compare it with a representative run.

A worksheet you can reuse

1. Define one completed business outcome, such as one accepted enquiry with one assigned follow-up.
2. List every trigger, search and action in the actual scenario.
3. For each step, record the expected input count, execution count and documented credit rule.
4. Add a separate assumption for branches, repeated work and the largest input you expect to handle.
5. Measure a small, non-sensitive sample in the run history and compare it with your estimate.
6. Apply the resulting units to the current plan quote, including any separate provider charges.

Choose an allowance after a representative trial

Keep a normal input, a multi-item input and an exception case in your trial set. Record how many business outcomes each run produced. The ratio of credits consumed to accepted outcomes is more useful than the cost of a successful-looking demonstration. If half the records need manual repair, a low credit total has not necessarily produced an economical workflow.

Review the estimate when you add a module, change an AI model, increase the number of items per event or alter the polling schedule. Keep the underlying assumptions alongside the number so that a colleague can explain why usage changed. Use your account's current allowance and terms before committing to a plan.

Estimate the shape of the data before multiplying actions

For a planning example, one order with three line items can become three bundles after an Iterator. If two fixed-rate downstream actions each run once per bundle, those actions represent six executions under the stated assumptions. Combining their results later does not erase work already performed. Use a routing truth table to identify which branches receive each item and keep retained retries as a separate budget assumption. These are illustrative execution counts, not a price quote or measured usage.