CRM architecture, databases and integrations — plus the alerting that makes them honest. Most automation fails quietly: an API runs out of credits, a snapshot job doubles up, a backfill kills the live feed and nobody notices for days. Mine says so.
CRM architecture in Zoho One or SmartSuite, a Postgres database behind an outbound team, a workflow where each stage opens the next. Built around how your business runs, not around the demo config.
Two tools holding the same records and disagreeing. A spreadsheet doing a database's job at 20,000 rows. Contracts retyped into three documents. I build the layer between them so nobody retypes anything.
An API out of credits, a sync that stopped silently, two rules overwriting each other, duplicate records multiplying nightly. I audit it, fix it, and make the next failure arrive as a warning.
Every entry is real work for a real client, described without naming them. Builds show what was asked for and what shipped; repairs show the symptom, the cause, and the fix.
Donations were tracked differently depending on who entered them, and pledges sat at 90% forever because the follow-up date lived in someone's head.
One pipeline was doing three jobs. There was no stage meaning “promised but unpaid”, so nothing could chase itself and every forecast was wrong.
Three linked pipelines that hand records to each other. Committing to a pledge creates the donation record with donor, family, campaign and solicitor carried across; it chases itself a week before the due date and marks itself lapsed after thirty days unpaid. Zoho Books issues the receipt.
Records multiplying nightly. Automations referencing fields that no longer existed. Two rules writing the same field in an order nobody controlled.
Years of additions with no audit. The record-creating automations had no lookup in front of them, so every re-run made another copy.
Audited every automation across three solutions, removed the broken and the redundant, made creation idempotent — update if it exists, create if it doesn't — and documented what remained in a register the client can read.
A dashboard tracking device activity stopped updating for two days. Separately, the same device was recording several “last seen” timestamps per day when the design allowed one.
Two faults. Historical data had been loaded without updating the script handling current data, and the daily snapshot job was running more than once, duplicating rows per device.
Restored the live feed by reinstating the missing trigger, changed the snapshot to run once daily and screen historical rows, then reconciled the report pages so one is authoritative rather than three disagreeing.
Every new client meant manually creating a Drive folder, copying a contract template, retyping their details into it and remembering to send an intake form.
Not a tooling gap — a preference. She was never going to adopt a CRM, and saying so was advice she would never take.
Built the CRM inside the spreadsheet. A dashboard is the only sheet she touches; a button emails a pre-filled intake form, and the submission provisions the Drive folder, merges the contract, writes the link back and advances the record. Contract signed then creates the customer and draft invoice in QuickBooks.
The numbers existed but every figure was rolling, so nobody could answer whether this week beat last — and so nobody used them.
A dashboard that can't be compared to anything is decoration. The metrics also weren't decisions: they measured activity rather than what the business steers on.
One snapshot tab per department and one company trend view, on metrics that are decisions: quoting turnaround in days, quote-to-job conversion, percentage of enquiries followed up, revenue per team day attended, and invoices aging past thirty days.
Case managers were tracking years of relationship in task notes. Closing the task lost the history.
Tasks were being used for two incompatible things at once — what to do next, and what already happened.
A separate module for things that actually happened — a meal, a call, an event, a class — linked to the person, household, case manager and event. Each manager got a caseload view of their own people and a next-seven-days list. Tasks went back to being future actions.
Sales closed in one system, production tracked in another, and each shop stage recorded wherever it happened to land.
There were no handoffs. Every stage transition depended on a person remembering to make it.
Each stage now opens the next. A won sale opens a project carrying scope, drawings and install dates; ready-for-finishing opens a finishing record with its inspection checklist; completing it advances the parent and opens assembly, touch-ups, then photography.
Family registration arrived as a form and left as retyping — a household, a parent, one record per child and an enrolment, all keyed by hand.
The form created blindly. With no identity field, nothing could recognise a family that had registered before, so returners duplicated.
A single submission mapped onto all four records, matched on email so returning families update instead of duplicating. The enrolment can't advance to registered until every child attached to it has verified forms — one child or five, same rule.
Signing a new facility meant typing the same entity details into an order form, an exhibit and an invoice — three chances to get it wrong.
The documents were disconnected from the records that already held the data.
Signature documents mapped back to CRM fields — parent entity, state, address and signer on the order form; each facility's trading name, entity and monthly fee on the exhibit — with tiered subscription products behind them. Contract signed provisions the customer and a draft invoice, link written back.
Quotes that had gone quiet months earlier still counted as open, making every conversion figure a fiction.
No exit condition. Nothing ever left the pipeline unless a person decided it was dead.
Time-based exits — 24 hours after follow-ups complete, 72 at terms-sent — copy the record into a nurture board with a link back and remove it from the pipeline. The board tracks last visit, call and seasonal email, and calculates who is due next.
An agency wanted to know when deals moved and when invoices went overdue, without anyone opening the CRM or the accounting system to check.
The data existed in two systems nobody watched. Notifications also needed enough context to be actionable — a name alone tells you nothing.
Won-deal alerts pushed into Slack carrying employee size, business type, city, state and products, then the same pattern inverted for lost deals with the reason attached. Overdue invoices from the accounting system raised automatically as tasks in the team's project tool.
An outbound team working from purchased lists with no way to tell which accounts resembled the ones that actually closed.
Bought data goes stale and can't be reasoned about. The useful version is built from enrichment APIs and kept current, with identity resolved so the same person doesn't appear three times.
A Postgres database assembled from enrichment APIs — profiles deduplicated, firmographics attached, lookalike sets derived by query from closed accounts, and total-addressable-market analysis run off the same tables. Job-change detection enrolls a contact into the right sequence within days of them moving.
Most of this work has a known shape, so it has a known price. Scoped calls and fixed-price builds are listed below. Anything larger gets a written scope with a fixed number before I start — you should never get an invoice you haven't already seen.
You describe the problem, I tell you what's actually wrong and what it takes to fix it. Screen shared, no slides.
One system's records appearing correctly in another, on a schedule, with failures that announce themselves.
The system designed around how you actually sell or deliver — stages, roles, permissions, automation, and reporting that reconciles.
Something that used to work stopped, or works but nobody trusts it. I find the cause, fix it, and instrument it so the next failure is loud.
For when a spreadsheet is doing a database's job — 20,000 rows, five people editing, and no version anyone believes.
For teams who have systems running and want someone who already knows them on call. No minimum retainer, no lock-in.
The same sequence whether it's a $250 repair or a $3,200 migration. The point of it is that you know the number and the shape of the thing before I write anything.
Through the chat or a scoped call. What you're trying to build, or what's failing, and what it's costing while it's broken.
What I'll build, what it will and won't do, what I need from you, the fixed price and the date. You approve it before anything begins.
Progress where you can see it, in your tools. You test as it goes rather than at the end, so surprises arrive early and cheap.
Documentation, admin access, and monitoring on every job. If something fails afterwards, you find out from the system, not from a customer.
Two ways in. Message me and I'll answer myself — if I'm at my desk it's a live conversation, and if I'm not it reaches me as a ticket and I reply within one working day. Or put a time straight in my calendar.
Describe the system you need or the thing that's failing. No form to fill in first — just tell me what's going on and I'll tell you whether it's a $250 fix or a $3,200 build.
Screen shared, no slides. You walk me through the stack, I tell you what I'd change and what it costs. Live availability, booked the moment you pick a slot.