Make automation for B2B processes a scenario you can read on one screen
Make (formerly Integromat) draws an automation as a scenario: the trigger, the modules, the branches and the error handling all sit next to each other on one screen. We design those scenarios for companies that already run on common SaaS tools and want a result in days, not in a quarter. No server, no code, and a bill you can work out before anything is switched on.
- 1 to 10 dayshow long a Make build takes after the workshop, from a single scenario in one working day to a flow with several branches in a week or two
- 1,500 appsthe size of the Make connector catalogue, so the common systems get wired up with a ready connector instead of an integration written from scratch
- 10,000 operationswhere paid Make plans start, with 1,000 a month on the free plan, so the running cost of a scenario is known before it goes live
The problem
How many times a week does someone in your company retype the same data?
A salesperson closes a deal in the CRM. Then someone opens a project in the task system, posts on Slack, creates the client folder on the drive, sends the welcome email and adds a row to the active projects sheet. That list takes about 20 minutes. Sometimes it gets done within half a day, sometimes on Friday afternoon, and sometimes it does not get done at all, because the person who owns it was on leave.
Worse than the 20 minutes is that nobody knows whether the list was finished. The client got the email but has no folder. The project is in the task system but has no owner. The process lives in one person's head and on a note stuck to a monitor, so every absence starts it over.
The cost on the other side is countable too. Make pricing is billed in operations: the free plan gives 1,000 operations a month, paid plans start at 10,000, and one module call is one operation. So before launch you know how many runs a month the scenario will make and which plan it fits into. Check the current thresholds and rates at that link, because the vendor changes them.
- The same information typed by hand into three systems, spelled differently each time
- A new client waits for access to the project because someone skipped one step
- The onboarding process exists only in one person's head
- Nobody knows whether yesterday's runs went through until a client writes in
Why now
Why Make rather than a script on a server?
Make shows an automation as a drawing. The trigger on the left, the modules in execution order, the branches spreading out sideways. Someone who has never read a line of code looks at the same screen we do and sees where the process forks and what happens when an order arrives without a VAT number. That turns the conversation about automation from trust into inspection.
The second thing is branching and error handling without code. A router splits the flow on a condition, a filter lets through only what meets a rule, and an error handler decides whether a failed step retries, takes a side path or calls a person. In a script each of those is developer work and later maintenance. In Make it is a few clicks the whole team can see.
The third is ready connectors and no server. The Make catalogue holds more than 1,500 apps, so HubSpot, Shopify, BaseLinker, Google Workspace or Slack get connected without writing an integration. There is no machine to maintain, patch or take down for service. For systems with no connector there is the HTTP module and the API, which covers the rest. And when the team would rather ask about the data in a plain sentence than click through systems, we put BOND, our company AI agent, next to the scenarios.
What changes
What does a company get once the scenarios are running?
A non-technical person can read the automation
A scenario is a drawing, not a code file. The operations manager opens it, follows the path from the trigger to the last module and says out loud where a step is missing.
A screenshot of the scenario is enough in a team meeting, with no technical translator in the room
Exceptions handled, not swept aside
We design more than the path where everything works. A router splits the cases, a filter rejects incomplete data, and the error handler decides what happens to a step that failed.
Router, filter and error handling set by clicking, without a line of code
Live without a server and without an IT department
Make runs in the vendor cloud, so there is no machine to set up, update and watch. The first scenario goes live on the day the process is written down.
A simple form to CRM scenario goes live within one working day
The systems you already have, with nothing rewritten
CRM, shop, accounting and messenger get connected with ready connectors from the Make catalogue. Internal systems with an API are wired in through the HTTP module, so nothing changes on your side.
More than 1,500 apps in the Make catalogue, plus the HTTP module for the rest
The bill worked out before launch
Make bills operations, and the number of operations per run is visible in the scenario. We multiply it by the real run count from your data and know which plan the process fits.
Paid Make plans start at 10,000 operations a month, and you know the threshold before rollout
A failure visible before the client notices it
Every scenario gets monitoring and an error notification. Plus documentation that says what each module does and who is meant to fix it.
A notification about a failed run on Slack or by email, the same day
And in your company
What if Make is the wrong tool?
Four sentences we hear most often, and what we answer. In two of these cases the answer is: not Make.
Our data cannot leave our own infrastructure.
Then Make is the wrong choice and we say so plainly. Make is a vendor cloud, so the data passes through its servers and no configuration gets around that. Where the data has to stay with you, we go with n8n on your own machine or an integration written against the API.
We are afraid the bill will explode once volume grows.
That is a real risk, which is why we cost it in the workshop. One run consumes as many operations as it makes module calls, so at hundreds of thousands of runs a month, billing per operation stops paying off. In that case we recommend n8n or a custom integration, and we show you the calculation behind the recommendation.
Nobody here knows how to program.
That is exactly why we propose Make. A scenario is changed by dragging modules, not by editing a file. After rollout you get documentation and training, so adding a new address to a notification or changing an alert threshold does not require a ticket to us.
We already have a few Make scenarios and they keep breaking.
Usually because they were built as the path where everything works. There is no filter for incomplete data, no error handling and no monitoring, so the first unusual record stops the run quietly. We review what you have and tell you what can be repaired and what is worth redrawing from scratch.
- CRM
- HubSpot, Pipedrive, Salesforce, Zoho
- Sales and e-commerce
- Shopify, WooCommerce, PrestaShop, BaseLinker, marketplaces
- Finance and accounting
- Xero, sevDesk, Fakturownia, Comarch Optima, QuickBooks
- Team tools
- Google Workspace, Microsoft 365, Slack, Notion, ClickUp, Jira, Asana
- Data and reporting
- Google Sheets, BigQuery, GA4, SQL databases
- Automation layer
- Make, n8n, Zapier, custom API integrations
When Make, and when something else
The recommendation is settled in the workshop, on your process and your run count. Below are the situations that decide it most often. The first two rows rule Make out, however convenient it would be to use here.
| Your situation | What we recommend | Why |
|---|---|---|
| The data has to stay on your server | n8n on your own infrastructure | Make is a vendor cloud and the data passes through it |
| Hundreds of thousands of operations a month | n8n or an integration over the API | at that volume, billing per operation stops paying off |
| Common SaaS systems: CRM, shop, drive, messenger | Make | the connectors already exist, first scenario in one working day |
| One step: website form into the CRM plus an email | Make, entry paid plan | 10,000 operations a month covers that scenario with room to spare |
| Several branches, conditions, exceptions and retries | Make with routers and error handling | the whole logic is visible on one screen, without code |
| An internal system with no public API | a custom integration or a change on the system side | there is nothing for a connector or the HTTP module to attach to |
| The team wants to ask about data in a plain sentence | Make plus an AI agent | the scenario moves the data, the agent answers questions about it |
We work with Make, n8n and Zapier, so we have no interest in talking you into one of them. The tool follows from what the process looks like and how many runs it has.
How we work
Five steps from a list of chores on paper to a scenario in production
Every step ends with something you can judge before you decide on the next one.
Workshop
We break the process into steps: what starts it, who does what, in what order, and what happens when the data is incomplete. We count runs per month and operations per run, so the tool recommendation rests on a number rather than on habit.
Scenario design
We draw the scenario in Make: trigger, modules, routers for the branches, filters for the data that must not go further, and exception handling. We walk you through it on one screen before anything touches production.
Test on test data
We run it on test data and on your own odd cases from recent weeks: an order with no VAT number, a client with two addresses, a record with an empty required field. We keep fixing until each of them ends the way we said it would.
Production with monitoring
Once you sign it off we switch the scenario to real data and turn on error notifications. We watch the runs for the first few days, because production always brings a case the tests did not.
Documentation and training
We hand over module by module documentation and train the team on the basics: where to see the run history, how to resume a failed run, how to change who gets the notification. The point is that changing an alert threshold does not require a ticket to us.
Before and after
How the week changes for the person who runs operations
Before
- After every closed deal, the same data typed into three systems, about 20 minutes
- Checking by hand whether the last onboarding was finished
- A campaign report assembled from three exports in a spreadsheet
- News of a broken integration arrives from the client
After
- The scenario runs the whole list itself, within a minute of the deal closing
- The run history shows what went through and what stopped
- The report fills itself and she only reads it and adds a comment
- An error notification lands on Slack before the client notices anything
The first scenario usually runs 1 to 10 working days after the workshop. We judge the effect after 30 days on the run history, and after 90 days we look at how many operations the process really consumes and whether the plan is the right one.
For the person signing this off
What an operations director gets out of it
The process stops depending on who is at work. The scenario is visible, documented and has a run history, so the question whether onboarding finished for three new clients is answered from a screen instead of by ringing round the team. The project risk is capped on the other side as well: with Make you are not buying a server or a quarter-long rollout, you are buying a scenario that can be switched off in a minute.
The second point matters more in a board meeting. You know the tool cost before the decision, because Make bills operations and the operation count per run is visible in the scenario. You pay the vendor directly, with no margin from us, so the bill is predictable and does not creep up quietly along with the scope.
- The process written down and visible, independent of any one person
- The first scenario in production in 1 to 10 working days, with no server
- Tool cost calculated before rollout and paid straight to the vendor
- Changes to the scenario made by your own team, after training
What it costs
The workshop has a published price, the rollout is quoted after it
The process workshop costs EUR 3,500 net per week, and runs from 1 to 7 weeks depending on how many processes are in scope. For a single Make scenario one week is usually enough, because the process is narrow: from the trigger to the last module. We quote the rollout after the workshop, once it is clear how many branches there are, how many systems have to be connected and what state the data is in.
You pay the Make subscription directly to the vendor, with no margin from us. The same goes for model costs if the scenario includes a step with a language model, where a query costs the provider roughly EUR 0.005 to 0.07. That keeps the tool bill on your side, so you can change it or switch it off without a conversation with us.
Process workshop
EUR 3,500 net
per week, from 1 to 7 weeks depending on how many processes are in scope
A self-contained piece of work. It ends with the process written down, the operation count calculated and a tool recommendation you could act on without us.
- A process map with steps, exceptions and the places where it stalls today
- Runs and operations per month calculated on your own data
- A tool recommendation: Make, n8n, Zapier or an integration over the API
- The metrics to measure against after 30 and 90 days
- Most popular
Workshop and Make rollout
Quoted after the workshop
scope follows from the number of branches and systems in the scenario
The option most companies choose. A working scenario in production 1 to 10 working days after the workshop ends.
- Everything in the workshop
- A Make scenario with routers, filters and exception handling
- Connection to your CRM, shop, accounting and messenger
- Tested on test data and on the odd cases from your production
- Error monitoring, module by module documentation and team training
Make and an AI agent
Quoted after the workshop
for teams that ask about the same data several times a day
Everything in the rollout plus BOND, the company AI agent that answers questions about the data your scenarios move.
- Everything in the Make rollout
- BOND wired into your systems, answering from company data in 5 to 10 seconds
- Alerts on stopped runs and on thresholds you set yourselves
- Agent rollout takes around 2 months, the scenarios run earlier
If the workshop shows that Make is the wrong tool for your process, because the data cannot leave your server room or there are too many operations, we say so and point to the alternative. If it shows there is nothing to automate yet, because the process changes every month, we say that too. The workshop ends with a document that stands up without us, including in front of a different supplier.
Frequently asked questions
What is Make and how is it different from Integromat?
Make is an automation platform with a visual editor in which the automation is drawn as a scenario: a trigger, modules in execution order, branches and error handling. Integromat is the former name of the same tool, changed in 2022, so when someone in your company says they have scenarios in Integromat, they are talking about Make.
How long does a Make rollout take?
From 1 to 10 working days after the workshop, depending on complexity. A simple scenario where a website form lands in the CRM and triggers an email goes live within a single day. A flow with several branches, conditions and exception handling takes a week or two, and a good part of that goes on testing the unusual cases.
When is Make the wrong choice?
In two situations. The first is a requirement to keep data on your own infrastructure, because Make is a vendor cloud and the data passes through it. The second is very high volume, hundreds of thousands of operations a month, where billing per operation stops paying off. In both cases we recommend n8n on your own machine or an integration written against the API.
How much does Make itself cost?
You pay the vendor directly, with no margin from us, and the plan depends on the number of operations. The free plan gives 1,000 operations a month and paid plans start at 10,000. One module call is one operation, so in the workshop we multiply operations per run by the real number of runs and know which plan the process fits into.
What happens when a scenario breaks?
Every scenario gets exception handling and monitoring. A failed step either retries, takes the fallback path, or stops the run and sends a notification to Slack or by email. The run history shows which module failed and on what data, so the repair does not start with guesswork.
Can we add a new step to the scenario ourselves?
After training, yes, and that is one reason we propose Make to non-technical teams. Changing who receives a notification, adding a field to a sheet or adjusting an alert threshold is work in the editor, not in code. For a new branch with conditions and exceptions you will usually come back to us, but that is your decision rather than a necessity.
We already use Zapier, is it worth switching?
Not always, and we will tell you so. Zapier has the largest catalogue of ready connectors, and on simple two-step automations the difference is cosmetic. Make wins when the flow has branches, conditions and error handling, because it shows them on one screen instead of splitting them across separate automations.
Will Make connect to our internal system?
If the system has an API, yes: we use the HTTP module and connect it without a ready connector. If there is no API, that cannot be worked around on the Make side, and then we talk about a change on the system side or a different tool. You get the answer to this question in the workshop, not halfway through a rollout.
Let us put your process on one screen
The free consultation takes 30 minutes. You describe what someone does by hand today after a sale, an order or a ticket. We tell you whether it can be built in Make, how many runs a month that works out at, and whether Make beats n8n in your case. You do not have to share any systems at this stage.
We run at most two rollouts at a time, so that someone is genuinely sitting on each of them.
Book a free consultationPS. If there is still a list of chores someone walks through by hand after every new client, that is exactly this problem. A Make scenario does it in under a minute and leaves a run history behind, so you never have to ask anyone whether it went through. You write directly to Pawel, the founder of JustAutomate. Process first. Tools second.