A Make.com expert builds scenarios: visual workflows in Make where a trigger starts a run and a chain of modules reads, changes and sends data between your apps. The job is part process analyst, part integration developer, and part accountant, because every module you add has a running cost.
Make, formerly called Integromat, shows each scenario as a canvas of circles joined by lines. A simple one might watch a Google Form, look up the customer in a sheet and send an email. A serious one branches with routers, loops through line items with an iterator, calls an API that has no ready module, writes to two systems and handles every failure path. The canvas makes it look easy. The hard parts are invisible: what happens when the CRM is down, when the same lead arrives twice, or when a payment is only partly captured.
So a good Make.com expert spends the first days away from the canvas. We list every event that should start a run, every decision a person makes today, every system that must be updated and every message that must go out. Only then do we sketch the scenario and count its modules.
- Mapping the current manual process into triggers, decisions and outputs
- Designing scenarios with routers, filters, iterators and aggregators
- Connecting apps through ready modules, webhooks or raw HTTP calls
- Adding error handlers, alerts and a way to replay failed runs
- Estimating monthly credit use so your Make plan fits the volume
When is Make.com the right automation tool for an Indian business?
Make fits best when you use several cloud apps, your rules branch in more than one direction, and your monthly volume is in the thousands of runs rather than millions. It is a poor fit when data must stay on your own servers, when every run involves hundreds of steps, or when your key software has no internet-facing API at all.
Typical good fits we see in India: a manufacturer on IndiaMART who wants every enquiry in a CRM within minutes, a D2C brand that needs orders, payments and WhatsApp updates in step, a coaching institute that routes demo-class leads to counsellors by course, and a services business that wants a daily sheet of new leads by source.
Typical poor fits: a factory whose only system is a desktop accounting package with no network access, a platform sending lakhs of messages a day, or a hospital whose patient data cannot leave its own infrastructure. For the first, RPA bots or a local connector may be needed. For the second and third, self-hosted tools or custom code usually make more sense.
Choose Make when
Your apps are cloud based, rules branch by product, city or source, volume is moderate, and you value a visual map your team can read.
Look elsewhere when
Runs number in the hundreds of thousands a month, data residency rules apply, or the key system has no API and lives on one office PC.
How does Make.com pricing work: credits, not per-user seats?
Make charges by credits. According to Make's pricing page, each module action in a scenario, such as adding a Google Sheets row or fetching Gmail data, counts as one credit, while router and error handler modules do not consume credits. Older tutorials and forum posts talk about “operations”, which was Make's earlier unit; Make's own help centre now marks that article as soon outdated.
This matters more than most people expect. A scenario with eight modules that runs 3,000 times a month uses roughly 24,000 credits, and an iterator that loops through 20 order lines multiplies the modules inside it by 20. A Make.com expert who ignores this can hand you a scenario that works perfectly and costs several times what it should.
Make's pricing page lists a Free plan with 1,000 credits a month and a maximum of two active scenarios, which is enough to test an idea but rarely enough to run a business process. Paid plans raise the credit allowance and, per the same page, allow a scenario run of up to 40 minutes, against 5 minutes on Free. Check the live pricing page before buying, because plan names and allowances change.
Our quote always includes a credit estimate per scenario, with the assumptions written down: runs per day, modules per run, loops and polling. You then choose the plan with numbers in hand instead of guessing.
Make.com vs Zapier: which one should you pick?
Pick Zapier for short, linear jobs where you want the simplest set-up; pick Make when the logic branches, loops or needs detailed error handling at moderate volume. Both are cloud tools with large app libraries, and both are sensible choices.
The billing models differ in a way that changes design decisions. Zapier's pricing page says tasks are counted only for successful action steps, and that triggers, polling and its built-in tools such as Formatter, Paths, Filter and Delay do not use tasks. Make counts most module actions, including data transformation modules, as credits, but not routers or error handlers. So a Zapier workflow heavy on formatting can be cheap there, while a Make scenario heavy on routing can be cheap on Make.
Zapier's Free plan, per its pricing page, allows 100 tasks a month and only two-step workflows. Make's Free plan allows 1,000 credits and two active scenarios. Neither free tier is meant for production. The better question is which tool your team will be able to read in a year. Make's canvas shows branches visually, which operations managers often find easier to follow than a long list of steps. Zapier's editor is faster for a non-technical person to change a single field. Our Zapier expert page goes through Zapier builds in detail.
How a Make.com expert designs routers, filters and fallback routes
A router splits one incoming bundle into several paths, each guarded by a filter, so different cases get different handling. Make's help centre notes that routes are processed one after another, not in parallel, and that a fallback route catches data that matches none of the other conditions.
That sequential behaviour has practical consequences. If route one writes a lead to the CRM and route two sends a WhatsApp message that includes the CRM record link, the order must be right or the link will be blank. We set route order deliberately and write it on the scenario map.
Filters deserve the same care. A filter that checks “city equals Pune” fails silently for “pune”, “Pune ” with a trailing space or “Poona”. We normalise text before filtering: trim, lower-case, map known variants. Numbers arrive as text from many Indian form tools, so amounts are converted before any greater-than comparison.
The fallback route is the one most self-built scenarios lack. Without it, a lead from a new source or a product code nobody expected simply disappears. With it, the bundle lands in a “needs attention” sheet and someone gets an email. On every scenario we build, the fallback route exists, even if it only logs and alerts.
- Route order written down and tested with a bundle for each path
- Text normalised before comparison; numbers converted from text
- One fallback route that logs and alerts, never a silent drop
- Filters kept simple; complex rules moved to a lookup table
Make.com error handling: what happens when a module fails?
Without error handling, a failed module stops the run, and a scenario that keeps failing can leave you unaware for days that orders have stopped flowing. With handlers, each failure follows a rule you chose in advance.
Make's help centre describes five handler types. Ignore drops the failing bundle and carries on with the next. Resume substitutes an output you define and continues. Commit stops the run and keeps changes already made in database apps. Rollback stops the run and reverts changes where modules support transactions. Break removes the failing bundle and stores it, with the remaining flow, as an incomplete execution.
Incomplete executions are the safety net. Make's documentation says storing them is off by default and has to be turned on in the scenario settings; once on, failed runs wait in a tab where they can be retried, resolved or deleted. We switch it on for every business scenario and decide per module which handler fits.
A rough rule: use Break with retries for temporary problems like a CRM timeout; use Resume when a missing optional field should not block the order; use Ignore only for truly disposable data; and add an email or WhatsApp alert to a person whenever money or a customer promise is involved.
Connecting Make to IndiaMART, WhatsApp, payment gateways and Tally
Most Indian tools can be joined to Make, but many need a webhook or raw HTTP call rather than a ready-made module, and each has its own limits. Knowing those limits is where a Make.com expert with Indian clients saves you trial and error.
IndiaMART: its help documentation for the CRM Pull API says the minimum gap between two calls should be five minutes, that more than five hits in a minute blocks the key for 15 minutes, and that one call can cover at most seven days. A Make scenario polling every minute will get locked out. IndiaMART also offers a Push API that sends leads as they arrive, which suits a Make webhook trigger. Our IndiaMART CRM integration page covers both routes.
WhatsApp: Make has a WhatsApp Business Cloud app with actions such as Send a Template Message. Meta's pricing documentation says free-form messages can only be sent inside the 24-hour customer service window opened by the customer, and template messages are the only type allowed outside it. Since 1 July 2025 Meta charges per delivered template message, so every automated WhatsApp step has a real cost.
Payments: Indian gateways generally send a webhook on payment events. We receive it in Make, verify the signature where the gateway supports it, and never treat a redirect page as proof of payment. Tally: TallyPrime accepts XML and JSON requests over its local HTTP port, which is not reachable from the internet by default, so a cloud tool like Make needs a small bridge on your network. See Tally API integration.
With BtechWaleTech, Make builds start at ₹40,000 (about US$600 for clients abroad). Your Make subscription is a separate cost, paid by you to Make and sized from our credit estimate. Other freelancers charge hourly, per scenario or per project, and quotes vary widely; compare what is included rather than the headline.
The build fee moves with five things. The number of scenarios and branches: one lead router is smaller than a lead router plus order sync plus reporting. Apps without modules: each raw HTTP integration needs authentication, pagination and error mapping. Data cleanliness: phone numbers with and without +91, duplicate leads, free-text city names. Error handling depth: a log-and-alert pattern versus replay with idempotency checks. And documentation: whether your team needs a written runbook to take over.
Running costs are Make credits, any WhatsApp template charges from Meta, and the subscriptions of the apps being connected. After two free months of fixes, maintenance starts at ₹8,000/mo if you want someone watching the scenario history. A cheap quote that skips error handling is not cheaper; it simply moves the cost to the day a failed payment goes unnoticed.
Hire a Make.com expert who asks how many runs a day you expect and what should happen when something fails, before talking about modules. Those two questions separate builders who have run scenarios in production from those who have only built demos.
Ask candidates to explain, in plain words, how they would stop a lead from being created twice if IndiaMART and your website both send it. Ask which error handler they would put after a CRM module and why. Ask how they would keep your credit use predictable. Ask whether you will own the Make organisation and every connection. Ask what you receive at handover.
Strong answers mention a unique key such as phone number or enquiry ID checked in a data store, Break with retries for temporary errors, filters placed before expensive modules, scenarios built in your account from day one, and blueprint exports plus a written map. Weak answers are “Make handles that automatically” or an offer to build in their own account and “share access later”.
- Builds in your Make organisation, never in their personal account
- Gives a credit estimate with assumptions written down
- Uses error handlers and incomplete executions by default
- Knows the rate limits of the Indian apps you use
- Hands over blueprint exports and a readable scenario map
Timeline: from first call to scenarios running on live data
A typical Make project takes two to four weeks: about a week to map and quote, one to two weeks to build, and a week of supervised live running. A single scenario repair can be quicker.
Days one to five: you walk us through the process on a screen-share and share read access to the apps involved. We draw the scenario map, list every app and its limits, estimate credits, and send an itemised quote within about two working days of the call. Nothing is billed until you approve it in writing.
Days six to fifteen: we build in your Make organisation, using a test copy of your sheet or a sandbox CRM pipeline where possible. Each route is tested with a crafted bundle, including the ugly cases: missing phone number, duplicate enquiry, payment failed, WhatsApp template rejected.
Days sixteen to twenty: the scenarios run on live data while the old manual process continues in parallel. We watch the execution history daily, fix anything odd, and compare counts: leads received versus leads created, orders paid versus orders written. When the numbers match for several days, the manual step is retired and the run notes are finalised.
Who owns the Make account, the connections and the blueprints?
You own everything: the Make organisation, the subscription, every connection and every scenario. We work as invited team members and can be removed the day the project ends.
This point is worth insisting on with any Make.com expert. If scenarios live in a builder's personal organisation, moving them later means rebuilding connections, re-registering webhooks with every app and hoping nothing is missed. Keeping them in your organisation from the first day avoids that trap entirely.
Connections deserve special attention. Where possible, connections are authorised with a shared business login you control rather than a personal employee account, so the scenario does not break when someone leaves. API keys for IndiaMART, your payment gateway or WhatsApp are generated from your accounts and stored in Make's connection settings, not pasted into text fields.
At handover you receive the blueprint export of each scenario (a file Make can re-import), a scenario map showing triggers, routes and handlers in plain language, a list of connections and whose login each uses, and run notes explaining the alerts and what to do about each. Payment and change terms are set out in your written quote; the general basis is on our terms page.
Where Make.com hits its limits, and what to do then
Make scales comfortably for most small and mid-sized businesses, but it has ceilings: credit cost at high volume, run-time limits per execution, rate limits of the apps you connect, and the practical difficulty of debugging a canvas with sixty modules.
Credit cost is usually the first wall. A scenario that loops through every row of a large sheet each hour burns credits whether or not anything changed. The fix is design: trigger on changes instead of polling, filter early, aggregate before writing, and use a data store to remember what was already processed.
Run time comes next. Make's pricing page caps a single execution at 40 minutes on paid plans. Bulk jobs, like syncing a full product catalogue, should be split into batches or moved out of Make.
Then complexity. When one scenario becomes a wall of routes, we split it into smaller scenarios joined by webhooks, each with one job. If volume or data-residency needs grow beyond what credits make sensible, the heavy parts move to n8n on your own server or a small Python service, while Make keeps the light, visual pieces. We tell you when that point is near rather than letting the bill grow quietly.
- Replace polling with instant webhook triggers where the app supports them
- Put filters before costly modules, not after
- Aggregate rows and write once instead of row by row
- Split giant scenarios into small ones joined by webhooks
- Move bulk or sensitive workloads to self-hosted or custom code
Is it safe to run customer data through Make.com?
Make is a hosted service, so your data passes through its servers during each run; whether that is acceptable depends on the data and your obligations. For lead names, order details and delivery updates, most Indian small businesses are comfortable. For health records or anything under strict contracts, check with your own adviser first.
Whatever the data, a careful build limits exposure. We pass only the fields a step needs rather than whole records. Execution logs keep data for a period set by your plan; the Free plan's history, per Make's pricing page, is kept for seven days. Sensitive fields can be masked before a notification is sent to a group chat. Webhook URLs are treated as secrets and, where the sending app supports signatures, verified.
India's Digital Personal Data Protection Act sets duties for businesses that process personal data, including consent and security safeguards. We build scenarios that support good practice, such as honouring opt-outs from WhatsApp messaging and deleting test data, but we do not give legal advice. Your own lawyer or CA should confirm what applies to your business.
Make.com expert services across India
We work remotely with businesses in every state, and the tools matter more than the city. Still, patterns repeat by region. Brassware makers in Moradabad and handloom exporters in Panipat receive steady IndiaMART enquiries that need fast routing. Footwear units in Agra want dealer orders pulled into one sheet.
D2C and SaaS teams in Noida, Gurgaon and Ahmedabad ask for order, payment and WhatsApp scenarios. Coaching institutes and clinics in Lucknow and Bhopal route enquiries to counsellors and send reminders. Tour operators and homestays around Kochi and Dehradun connect booking forms to calendars and payment links.
The working method is identical everywhere: a screen-share to map the process, invited access to your Make organisation, a shared WhatsApp group for questions and daily notes during live running. We do not visit offices, and a Make project never needs it; everything a Make.com expert touches lives in the cloud.
Worked example: a hypothetical Moradabad exporter's enquiry flow
Say a brass handicraft exporter in Moradabad gets enquiries from IndiaMART, its website and a trade-fair form, and loses some because they sit in different inboxes. This is an illustrative scenario, not a client story.
Scenario one receives IndiaMART leads through the Push API webhook, website leads through a form webhook and fair leads from a Google Sheet. Each bundle is normalised: phone number to a +91 format, product text trimmed, country set. A data store lookup on phone number and enquiry ID stops duplicates.
A router then splits the flow. Domestic bulk enquiries go to the sales head's CRM pipeline with a WhatsApp utility template to the buyer confirming receipt. Export enquiries go to the export executive with an email template. Small retail enquiries go to a sheet for weekly follow-up. The fallback route logs anything unclassified and emails the owner.
Error handling: Break with retries after the CRM module, Resume with a placeholder if the product lookup fails, and an alert if a WhatsApp template is rejected. Estimated use: about 12 credits per lead, so 1,500 leads a month would need roughly 18,000 credits. The owner sees one pipeline, the buyers get a same-hour response, and the plan is sized from the estimate rather than a guess.
Checklist before you hire a Make.com expert
Prepare these points and the first call becomes a planning session instead of a discovery exercise. Rough notes are fine.
- A list of every app involved and who owns its login
- Where each lead, order or request starts today
- What a person decides at each step, and the rules they use
- Expected runs per day now and in a year
- Which failures cost money or a customer promise
- Your WhatsApp Business Platform status and approved templates, if any
- Whether you already have a Make organisation, and on which plan
- Any data you would rather not send through a cloud tool
- Who will receive failure alerts, and by email or WhatsApp
- Whether you want the run notes in English or Hindi
Send these on WhatsApp and you will receive a scenario map, credit estimate and itemised quote in about two working days. If Make is the wrong tool, the plan will say so and suggest a WhatsApp-first automation or another route.