Make for Professional-Services Firms: A Hands-On Look at Client-Intake Automation

Why professional-services firms should care about workflow automation

Consulting and advisory teams run on information moving between people: a new client brief, a proposal request, a staffing requirement, a document request, a deadline, an approval or an exception. The operational problem is rarely that a team has no software. It is that the hand-offs between systems are manual, inconsistent and easy to lose.

Three examples make the opportunity concrete:

• Proposal creation: a qualified brief should trigger a consistent intake checklist, evidence collection and an accountable proposal owner - not a loose chain of messages.
• Staffing: an engagement need should surface relevant skills, availability and decision points for a human staffing lead. Automation can assemble the information; it should not silently allocate people.
• Client onboarding: incoming files should be collected into a controlled workspace, recorded against a request list and visibly flagged when information is missing, duplicated or ambiguous.

The common principle is simple: automation should do repetitive collection, formatting, routing and recording. A person should retain ownership, judgement and accountability.

The controlled Make test

To avoid using client or employer information, I used a synthetic Google Sheet containing fictional client-intake rows. The intended workflow was:

1. A new intake row appears in Google Sheets.
2. Make reads the row.
3. Relevant values are normalised - for example, client-name formatting and priority capitalisation.
4. Required information is checked.
5. The record is written to a Processing Log.
6. A complete high-priority intake follows an urgent notification route; a standard complete intake follows a standard route; incomplete inputs are retained for human review.

The test deliberately used only ordinary business data: client name, engagement type, owner email, priority, estimated value, document status and notes. It did not use real client information.

Plan and milestones

What worked first: a useful notification workflow

The first working scenario was intentionally small:

New Google Sheets intake row → Gmail notification to the engagement owner

The observed setup time was 7 minutes 30 seconds. A functioning end-to-end Test A took a further approximately 12 minutes of build, diagnosis and execution time. The successful run consumed two credits/operations: one for the Google Sheets trigger and one for Gmail.

The resulting email contained the correct fictional case ID, client, engagement type, priority, estimated value, document status and notes. It arrived exactly once.

That matters because it establishes the base case. A firm does not need an elaborate automation programme to get value from a clean, visible notification that prevents a new request from remaining buried in a spreadsheet.

What required more work than expected

1. The input must be a native Google Sheet

An uploaded Office workbook produced a 400 FAILED_PRECONDITION error. Saving it as a native Google Sheet and reconnecting it resolved the problem.

This is a small issue once you know it. It is not small when you are new to the builder and are trying to understand whether the failure sits with Google, Make or your connection.

2. A visible label is not always a live mapping

The Gmail module initially rejected the run because its recipient field was empty. The source module had to run first before the usable Google Sheets fields appeared for mapping. Text that looked populated in the builder was not necessarily a live mapped value.

For a professional-services team, this is a governance point as much as a usability point: every workflow needs a controlled test record and a person who verifies the actual output, not just the diagram.

3. “No-code” still includes logic

The multi-step workflow added variables for normalisation, validation, routing and processing status. It also used a Router with separate urgent and standard notification routes.

The high-priority synthetic case ultimately passed through the urgent route and generated the intended email:

[TT3][HIGH] New client intake: Northstar Foods Pvt Ltd

However, building those rules required comfort with functions, mapped fields, filter conditions, trigger start positions and run history. Some early attempts wrote an expression as text rather than evaluating it, reprocessed an earlier sheet row or reached the log without reaching either email route.

These were recoverable errors. They are also the honest reason I would not describe Make as effortless for a first-time, non-technical operator.

What the test says about Make’s learning curve

Make’s visual canvas is helpful because a business owner can see the process: trigger, transformation, log, decision and action. That is materially better than handing a non-technical person a code repository.

But the visual canvas does not eliminate the underlying concepts. Once a workflow needs conditions, data clean-up and exceptions, the operator needs to understand at least five things:

Make is approachable for simple automations. It becomes a low-code operating tool as soon as a firm wants reliable validation, branching and exception handling.

That is not a criticism. It is a staffing and ownership decision. A firm can adopt Make successfully when one person is willing to become the workflow owner, document the rules and test changes before they touch live operations.

What credit consumption means in practice

Make currently describes its pricing in credits, and module activity generally consumes credits. Its pricing page lists a free plan with 1,000 credits per month; scheduled scenarios on the free plan have a minimum interval. Check current plan terms before designing a production workflow because limits and prices can change. Make pricing ↗ and credit documentation ↗.

The observed test confirms why firms should model consumption rather than rely on a headline plan allowance:

• The simple Google Sheets-to-Gmail run used two credits/operations.
• A multi-step run uses additional modules for data transformation and logging.
• A run that stops at filters can still consume credits in upstream modules.
• Test and repair activity consumes usage too.

The right question is not “Is Make cheap?” It is: how many rows, files or events will reach each module in our actual workflow, and who will monitor exceptions?

Where Make can go next in a professional-services firm

The test above is not exhaustive. It proves one small client-intake path, not an end-to-end operating model. But the same control pattern - collect, validate, route, log and require review - can be tested in other workflows.

Proposal creation

Start with a qualified client brief. Make can be evaluated as a way to create a proposal workspace, issue a checklist, notify the accountable owner and collect comparable case studies from an approved library. Pricing, scope assumptions and final recommendation should remain human decisions.

Staffing and availability

Use a controlled skills-and-availability source to assemble potential staffing options for review. The useful question is not whether automation can “staff a project”; it is whether it can reduce the time spent finding relevant profiles while making conflicts and unavailable resources visible.

Client onboarding and document control

An onboarding workflow could record a file arrival, apply a controlled naming or metadata rule, update a request tracker and send incomplete or ambiguous items to a review queue. This is especially relevant where firms face duplicate uploads, accidental versions and repeated back-and-forth with a client.

Internal reporting

Recurring project data can be collected from approved systems into a review-ready operating dashboard. The workflow should flag missing source data and preserve the original record rather than silently “fix” it.

Each of these is a future controlled test. None should be treated as a production recommendation until the firm has defined data permissions, exception ownership, approval points and a rollback path.

A practical adoption playbook

If you are evaluating Make for a consulting or advisory firm, begin with one low-risk workflow - not the firm’s most sensitive client process.

1. Choose a repeated hand-off. Start with a new request notification, a document receipt log or an internal reminder.
2. Use synthetic data first. Confirm the happy path, one exception and one correction path before connecting live records.
3. Keep a Processing Log. Record what entered, what route it took, what action occurred and who owns the exception.
4. Default uncertain cases to review. Do not let automation guess its way through missing data or duplicate files.
5. Count modules and credits. Build a simple cost model from your likely monthly volume.
6. Name an owner. Someone must understand the rules, review changes and respond when a run fails.
7. Assess security separately. Before using confidential client data, review permissions, access controls, data processing, retention and contractual requirements with the appropriate internal stakeholders.

Limits of this article

This article is intentionally narrow.

• It documents one person’s (with a non-technical background) hands-on experience with a synthetic Google Sheets–Gmail client-intake workflow.
• The simple notification workflow passed; the advanced workflow was partially demonstrated through the high-priority path but was not completed across every planned route and exception case.
• It does not measure time saved, production reliability, security, legal compliance or return on investment.
• Some debugging time reflected experimental configuration decisions in the controlled test itself. It should not all be attributed to Make’s product design.

That limitation is useful. Software buying becomes more credible when the evidence boundary is visible.

Final view

Make looks promising for professional-services teams that want to automate repetitive operational hand-offs without building a custom system from scratch. The platform handled a basic client-intake notification cleanly and demonstrated that a more governed workflow - normalisation, routing, logging and notification - is achievable.

The trade-off is ownership. As workflows become more useful, they also become more logical: fields must be mapped correctly, rules must be explicit, exceptions must be visible and changes must be tested.

For a small consulting firm, that can be a worthwhile trade. Start with one controlled, reversible workflow; prove it with synthetic data; then expand only when the team can explain what the automation does, what it does not do and who is accountable when it needs help.

If that operating model suits your team, you can explore Make through our affiliate link ↗.