Hiring a senior Make.com architect to implement an existing, deterministic automation system for proposals, dispatch, billing, support, and document signing

Hire a Pro Hire Help
, , ,
1

:police_car_light: Hiring: Senior Make.com Architect / Certified Partner (Implementation Role)

We are hiring a senior Make.com expert or certified partner to implement and harden an existing automation architecture that runs our sales, operations, support, billing, dispatch, and document workflows.

This is not a greenfield design role and not a template-based automation job.
The architecture already exists. Your role is to build it correctly, deterministically, and cost-efficiently.

:locked: Non-Negotiable Requirements

  • You must be comfortable implementing state-aware systems (not linear zaps)

  • You must design for idempotency, retries, and recovery

  • You must respect approval gates, margin enforcement, and signatures

  • You must prioritize low SaaS cost and avoid unnecessary tools

  • You must document scenarios and recovery paths

If you primarily connect apps without architectural reasoning, this role is not a fit.

:brain: What You Will Be Implementing

1. Proposal & Sales Automation (XTEN-AV)

  • Structured customer intake

  • BOM + labor calculation

  • Margin enforcement

  • Dual document generation:

    • Customer proposal

    • Technician SOW

  • Approval + signature gating

  • Handoff to billing and operations

2. Operations, Dispatch & Billing

  • Project lifecycle management (state-based)

  • Contractor assignment and dispatch (Cloud|Work Pro)

  • Automated notifications (tech + customer)

  • Equipment lifecycle tracking

  • Billing triggers (OTF / MRC)

  • No duplicate dispatch or billing events

3. Document Signing & Notifications

  • Pre-job documents sent for signature

  • Tech acknowledgment before dispatch

  • Post-job completion documents + customer sign-off

  • State does not advance without required signatures

4. Customer Support Automation

  • Auto-response to email/SMS

  • AI-assisted answers using company + manufacturer docs

  • Confidence-based escalation to humans

  • Ticket creation and lifecycle tracking

  • No hallucinations, auditable responses only

:brick: Architecture Expectations (Critical)

  • Explicit lifecycle states:

    • Lead → Proposal → Approved Project → In Progress → Closeout → Closed → Support

  • Make Data Stores for:

    • state

    • idempotency

    • retries

  • Webhook-first design

  • Clear failure paths and manual recovery options

  • Deterministic logic > AI judgment

You will be given read-only architecture documentation that must be followed.

:white_check_mark: Required Experience

  • Advanced Make.com experience (senior level)

  • Strong API + webhook knowledge

  • Experience with complex, multi-scenario systems

  • Ability to explain why a system is designed a certain way

  • Clean documentation habits

Strongly preferred: Make.com Certified Partner / Pro

:paperclip: Supporting Documentation

We have existing architecture documents that will be shared with serious candidates.
You must be willing to review and implement them — not replace them.

:memo: To Apply, Please Include

  1. Your Make.com experience (years + examples)

  2. Any certification status

  3. One example of a complex system you implemented

  4. How you handle idempotency and retries

  5. Availability and time zone

We are looking for a long-term implementation partner, not a one-off builder.

4

Hello @not-AI , welcome to make.com community, I have worked and have experience with Make.com and l will love to collaborate with you on this you can schedule a call Here and you can checkout my upwork profile Here, for my pastworks and certifications

1 Like
5

With my experience in automating complex workflows across various industries, I can confidently say that I’m well-equipped to enhance and optimize your existing automation architecture.

I specialize in designing state-aware systems, ensuring idempotency and retries, and creating scalable, cost-efficient solutions. My focus is always on building robust systems with clear failure paths and recovery options, and I follow strict documentation practices to ensure clarity throughout the implementation process.

:page_facing_up: Check my profile: https://www.upwork.com/freelancers/farhana401

:telephone_receiver: Book a quick call:Calendly - Automaxion

6

Hi,

Welcome to the community.

Your post is very clear. This is not a simple automation job. It needs state tracking, approval gates, billing control, and safe retries. That is the type of system I build.

  1. Experience
    I have 2 years of advanced Make.com experience. I build multi-step systems that connect sales, operations, billing, dispatch, and document signing. I work a lot with APIs, webhooks, and Make Data Stores.

  2. Complex system example
    I built a system that handled proposals, approvals, dispatch, and billing. The biggest challenge was preventing duplicate billing or dispatch. I solved this using unique IDs, state checks, and “check before create” logic.

  3. Idempotency and retries
    I use Make Data Stores to track state and execution.
    I use unique transaction IDs.
    I add retry limits and clear failure paths.
    No blind retries.

  4. Availability
    I’m available long-term and can work with US time zones.

I’m happy to review your documentation and discuss next steps.

7

Hi there :waving_hand:,

Welcome to the community!!

This is exactly the kind of deterministic, state-aware architecture I specialize in implementing. Designing with explicit lifecycle control, idempotency, retries, approval gates, and documented recovery paths is how complex Make systems should be built.

I’ve implemented webhook-first, multi-scenario architectures using Data Stores for state tracking, retry logic, billing triggers, dispatch flows, document signing gates, and strict transition enforcement. I’m comfortable working from existing architecture documentation and hardening systems rather than redesigning them.

A few relevant questions:

• How are lifecycle states currently persisted and validated across scenarios?

• What mechanism is preventing duplicate billing or dispatch events today?

• Are retries time-based, event-based, or manually triggered?

• Do you have a defined rollback strategy if a mid-state failure occurs?

Experience: Senior-level Make.com architecture with advanced API and webhook systems

Idempotency & retries: Implemented using unique event keys, Data Stores, conditional routers, and controlled replay logic

Complex system example: State-driven proposal-to-billing automation with approval gates, margin enforcement, dispatch coordination, and audit logging

Availability: 15 hours daily

Time zone: UTC + 1.00 (London Time)

You can reach me directly at: folafoluwaolaneye@gmail.com

folafoluwaolaneye@gmail.com

Portfolio: View my past automation samples here.

Book a Call: Schedule Jobscope walkthrough session here.(P.S: Adjust to your timezone)

Or proceed via my Fiverr workspace:

http://www.fiverr.com/s/qD1jlXZ

Also, may I ask your name or brand name for proper communication?

Best regards,

Folafoluwa Stephen

Flowedge Digitals

1 Like
8

This is one of the best-structured briefs I’ve seen on this board. A few things stood out:

Your emphasis on **deterministic logic over AI judgment** tells me you’ve already been burned by systems that work 90% of the time but fail unpredictably on the other 10%. That’s the right instinct for billing and dispatch — these need to be provably correct, not probabilistically correct.

**Relevant experience:**

I recently architected a state-driven business intelligence system for an Amazon Merch seller (6,000+ product catalog) — similar lifecycle complexity: data ingestion, multi-agent analysis, approval gates, and notification triggers. The architecture uses explicit state machines, idempotency keys on every transaction, and a shared context layer so each module can read observations from others without coupling.

**How I handle your specific requirements:**

- **Idempotency:** Every webhook-triggered scenario gets a deduplication check against a Data Store using a composite key (event_type + entity_id + timestamp_hash). No duplicate billing, no duplicate dispatch — guaranteed.

- **Retries:** Dead-letter pattern — failed operations get logged with full context, retried with exponential backoff, and escalated to manual recovery after N attempts. No silent failures.

- **State management:** Explicit lifecycle states with transition validation — a project can only move from “Approved” to “In Progress” if all required signatures exist. Invalid transitions get rejected and logged, not silently ignored.

- **Approval gates:** Signature verification as a hard gate — state does not advance without it. I implement this as a separate validation scenario that the main flow must pass through.

**What I’d want to clarify before starting:**

1. Which document signing service are you using (DocuSign, PandaDoc, or built-in)?

2. Is Cloud|Work Pro the dispatch platform, and does it have webhook/API support?

3. For the AI-assisted support module — what’s the existing knowledge base format (PDFs, internal wiki, structured docs)?

4. What’s your current Make.com plan? Operations limits will affect architecture decisions.

**About me:**

- 1.5+ years building production automation systems — API-first, webhook-driven architecture

- Founder of Evara AI (incubated at IIT Bhubaneswar) — we build custom automation and AI systems for businesses

- Time zone: IST (UTC+5:30), available 20+ hours/week

- Strong documentation habits — every scenario gets a recovery playbook

I’m interested in the long-term partnership aspect. Happy to review the architecture documentation and walk through my implementation approach on a call.

Reach me at: priyanshukumarmaurya2224@gmail.com