Custom CRM Automation for Service Operations
When Salesforce, HubSpot, or Pipedrive workflows hit the wall on custom scoring, multi-step approvals, or non-standard pipeline shapes.
CRM platforms are built around a generic sales motion. Most service operations don't run a generic sales motion. The system fits the templated team that the vendor designed for, not the operation you actually built. The integrations talk to whatever templates exist; the workflows automate whatever the no-code layer permits; the reports show whatever the platform's data model can express. Past a certain complexity, that gap becomes the bottleneck. We write the integration in code so the system fits the sales motion you already have, not the other way around.
Pressure-test your bottleneck›Common stack today
- Salesforce
- HubSpot
- Pipedrive
- Close
- Zapier or Make for cross-system glue
- Slack for the workarounds
Where no-code tops out for CRM workflow
Custom scoring is the first thing to break. Lead scoring on most platforms is a weighted sum of fields the platform knows about. Real qualification logic involves cross-system signals (web visits, product usage, support history, seat count, deal source, intent data) that don't live in the CRM. No-code platforms can't reach those signals coherently. You end up with 'lead score' that everyone ignores because everyone knows it's wrong.
Multi-step approval workflows are the second thing to break. A deal over $50k routes through legal, finance, and the GM. A discount over 15% routes through the VP. A custom contract routes through the CRO. Most CRMs let you wire one approval per stage. They don't let you compose approvals or branch on multiple criteria. Teams work around this with Slack threads and follow-up emails.
Pipeline shapes get forced into the platform's defaults. A real service business has a pipeline that doesn't match what the CRM thinks a pipeline is. Multi-product, multi-segment, multi-stage with dependencies. The platform makes you flatten it; the team learns to manage outside the platform; the CRM stops being the source of truth.
And every Zapier glue layer added to patch these gaps becomes its own fragile, undocumented dependency.
What we build
We write a custom integration layer that sits next to your CRM, talks to it through its APIs, and handles the logic the platform can't. The CRM stays as the system of record for accounts, contacts, deals, and activity. Everything sophisticated runs in code we control: scoring against multiple data sources, multi-criteria approval routing, custom pipeline state machines, deal-shape validation.
The integration runs as services in your cloud account (AWS, Azure, or GCP). Failures emit alerts to a real logging system. Every change is in a Git repo with an author and a diff. The CRM keeps all the parts it's good at; we add the parts it's not.
When your sales motion changes, we change the code. When the CRM vendor changes their API, we change the code. When you outgrow this CRM and migrate to a different one, the integration logic is portable because it's not locked to a specific platform's automation layer.
How it's built
- Python or JavaScript for the integration logic
- PostgreSQL for shared state and audit logs
- Deployed to your existing AWS, Azure, or GCP account
- Real error handling, real observability, real version control
Frequently asked
How does this differ from a Zapier or Make automation?
Zapier and Make are excellent for connecting two systems and moving data between them. They start to break when the logic gets complex: cross-system scoring, multi-step approval routing with branches, custom pipeline state machines, anything that requires conditional execution against more than two data sources at once. Custom code handles all of that natively. The other big difference is observability. When a Zap fails, the failure is invisible until someone notices. When our code fails, it logs a real error to a real logging system that alerts a real human. For workflows your business actually runs on, that visibility is not optional.
Do you migrate existing automations or start fresh?
Both, depending on what's running today. Most engagements start with an audit: which existing automations are working fine and we leave alone, which are load-bearing but fragile and need to be rewritten in code, and which are duplicates or dead ends that can be retired. We rewrite the load-bearing fragile ones first. A common pattern is a HubSpot workflow that's mostly functional but silently drops records whenever a custom field is blank, or a Salesforce Process Builder chain that no one wants to touch because no one fully understands it anymore. The audit-and-classify step is part of the diagnostic call we offer before any commitment. It usually surfaces more salvageable automation than teams expect.
What CRMs do you integrate with?
We've integrated with Salesforce, HubSpot, Pipedrive, Close, and several internal CRMs over the years. The integration approach is API-driven, so the answer for any modern CRM with a documented API is yes. Salesforce's API surface is the largest and most complex; HubSpot and Pipedrive are more approachable but have their own model constraints. Close is well-suited to high-velocity sales teams but has a shallower automation API. The interesting question is usually not whether we can integrate but whether the integration logic should live in the CRM's automation layer or in custom code. For the use cases this page describes, the answer is custom code.
What happens to the code and infrastructure?
The infrastructure runs on your cloud account (AWS, Azure, or GCP), so the running system is already in your environment from day one. The source repository stays with us during the engagement and we maintain it actively. We document the architecture, the integration points, and the routing rules so the work is legible to any engineer who picks it up later. If the engagement ends, codebase handoff is part of the close-out process: we can transfer the repository to your internal team or transition it to another engineering partner you've selected. We've done both. Either way, the workflow is not locked behind a vendor platform's automation UI the way a Zapier integration would be.
What does an engagement look like?
First step is a thirty-minute call. The output is a written diagnostic, delivered within three business days, that scopes the build whether or not you hire us. It names the bottleneck, maps what's currently load-bearing versus what just feels rough, and gives you a concrete starting point. If you do hire us, the typical first build takes four to eight weeks depending on integration complexity. We deploy in stages, with checkpoints, so you can validate each piece before the next one lands.
Written and built by Charles Borden, founder of AutomationsHQ. Ten years of production systems engineering before this: ship control at Electric Boat, radar positioning at Raytheon. AutomationsHQ writes custom workflow automation for service operations whose stacks have outgrown Airtable, Zapier, and Make. Real production systems, not no-code patches. Mid Bay News reclaimed 100+ hours per week of manual work after we rebuilt their content aggregation pipeline.
Industries that need this
Custom Workflow Automation for Marketing Agencies
When client reporting, campaign deployment, and time-tracking-to-invoicing stop scaling on Asana, ClickUp, HubSpot, and Zapier.
Custom Workflow Automation for Recruitment Agencies
When requisition intake, candidate pipeline management, and placement billing stop scaling on Bullhorn or JobAdder and manual spreadsheets.
Custom Workflow Automation for Real Estate Brokerages
When agent onboarding, transaction coordination, and commission tracking stop scaling on Follow Up Boss, kvCORE, and manual spreadsheets.
Custom Workflow Automation for Consulting Practices
When proposal generation, SOW management, and project delivery status stop scaling on Notion, ClickUp, and HubSpot rules.
Want a written diagnostic of your bottleneck?
Pressure-test your bottleneck›Free, 30 minutes, no pitch.