Start with executions and records
Give every estimate a row for the operation, number of executions, returned records and any variable charge. A check that finds ten items is not the same as ten writes followed by ten notifications. Keep the quantities explicit. This makes it possible to revise the model when a search returns several matches or a request expands into multiple line items.
Work through a 30-day daily-check model
Assume one credit per trigger check and one per record for each of two downstream actions. With 30 daily checks and N enquiries, the model is 30 + 2N. It excludes lookups, duplicate checks, repeated line items and recovery. Add those operations when the design needs them instead of continuing to quote the simpler total.
- 100 enquiries: 30 + 100 × 2 = 230 credits.
- 1,000 enquiries: 30 + 1,000 × 2 = 2,030 credits.
- 10,000 enquiries: 30 + 10,000 × 2 = 20,030 credits.
Include the cost of checking more often
A 15-minute check around the clock for 30 days produces 30 × 24 × 4 = 2,880 checks. If each check in your selected module costs one credit, that component alone is 2,880. Verify what empty checks actually consume for that module. Decide how long a person can wait for the result before choosing a short interval merely because it is available.
Add fan-out and partial recovery
If each order has three items and each item needs two actions, that segment involves six actions per order. If 50 of 1,000 requests later require only two actions to be repeated, add 100 under this model. Replaying the entire workflow is a different assumption. Replace the provisional recovery rate with observed counts after the process has run normally.
Keep AI usage in a separate model
Do not extend the fixed-credit example to every AI step. Inspect the connection method and its displayed charging rule, then identify any separately billed provider usage. For a summarization task, short and long inputs need different assumptions. Keep that estimate separate until you know how the chosen module accounts for both operations and model consumption.
Common question: does the same diagram mean equal usage?
Two diagrams with three modules can have different usage if an intermediate step returns one record in one case and ten in another. A supposedly unique lookup returning multiple matches can also cause repeated notifications. Inspect the search condition, result limit and number of records passed downstream together.
Label the unit behind every “per item” estimate: an order, line item, email and notification are different things. When usage spikes, trace where record counts multiplied instead of explaining everything through the number of incoming requests. This also makes a cost investigation useful for finding a workflow defect.
Reconcile the model before choosing a plan
Check a normal item, a larger item and an empty interval in a controlled environment. Compare the observed module activity with your worksheet and explain discrepancies. Separate filtered records from those reaching a write or notification. Only then scale the estimate to normal and busy months, and assign someone to review allowance consumption before the next billing cycle.
Start a small workflow in Make
Try the required workflow with practice data, then choose a plan around its usage and features. Check current prices, promotions and eligibility in the official signup flow.
Sign up on MakeAffiliate linkEstimate costs for your workload
Enter monthly jobs, billable steps and retries to see how different billing units affect your estimate.
Open cost calculatorOfficial sources
Pricing, availability and feature limits can change. Check the linked official pages before subscribing.
- Make creditsInformation checked: 2026-10-26
- Test your scenario and inspect bundlesInformation checked: 2026-10-29
- Schedule a scenarioInformation checked: 2026-10-29
- Make pricing — Core at 10,000 monthly creditsInformation checked: 2026-10-28
- Make scenario settingsInformation checked: 2026-10-26