Intent boundary: This page decides an architecture pattern, not a specific vendor winner. “Build” means assembling and maintaining integrations around owned workflows; it does not imply writing an entire FSM from scratch.
Map the service transaction before choosing the stack
Capture identity, source, consent, and request
Lead forms, phone systems, ad platforms, inboxes, and AI intake tools often create the first record. Choose where customer identity and communication permission become authoritative.
Turn request into scope, price, and schedule
The system of record should own the operational promise: property, work scope, estimate version, assignment, arrival window, deposit, and status.
Complete work and collect field evidence
Mobile time, notes, photos, forms, equipment, materials, signatures, changes, and payment need one durable job context, not loosely joined copies.
Post the financial result and reconcile
Invoices, payments, fees, refunds, tax, cost, and payouts cross a high-risk boundary. The architecture must name direction, trigger, correction, and exception owner.
Automate follow-up without breaking truth
Messaging, reviews, reporting, and AI may consume the operational record, but they should not create competing customer, job, consent, or financial truth.
Three viable architecture patterns
The build-versus-buy control sheet
| Decision factor | All-in-one signal | Composable signal | Proof required |
|---|---|---|---|
| Workflow differentiation | The process is well served by configurable defaults | The operating model creates durable advantage that standard configuration removes | Timed baseline and documented gap with economic consequence |
| Data ownership | One FSM can own customer, job, and financial-operating state | Multiple sources are unavoidable and a canonical model is funded | Object map, IDs, direction, retention, and export test |
| Exception volume | Native workflows cover common failure paths | The business can monitor, retry, reconcile, and replay integration failures | Thirty-day exception forecast and named response time |
| Technical capacity | Operations can administer roles, templates, and approved apps | A durable owner can secure credentials, maintain versions, test releases, and support incidents | Named owner, budget, runbook, and coverage during absence |
| Change frequency | Vendor release cadence and roadmap are acceptable | The workflow changes faster than vendor configuration can support | Twelve-month change log and regression-test cost |
| Three-year economics | License, add-ons, implementation, and exit remain favorable | Measured gains exceed integration build, run, incident, and replacement cost | Conservative total-cost and downside scenario |
Direct-test protocol: prove one transaction end to end
Declare systems of record
For customer, property, consent, estimate, job, invoice, payment, accounting, files, and reporting, name exactly one authoritative system and every permitted copy.
Pass when: No critical object has two editable masters.Draw triggers and contracts
For every handoff, document event, payload, identifier, required fields, permission, timing, retry, deletion, and version behavior.
Pass when: A new operator can explain when and why each record crosses the boundary.Run the transaction
Create a lead, estimate, reschedule, field change, invoice, payment, refund, accounting post, follow-up, and report across the proposed architecture.
Pass when: Every system shows the intended state with no duplicate entry.Break three handoffs
Expire credentials, remove a required field, and deliver the same event twice; then retry after the destination recovers.
Pass when: Alerts reach an owner, replay is safe, and duplicates are prevented.Simulate change and exit
Change an API field or connected user, remove one connector, export core history, and estimate the work to replace the automation layer.
Pass when: The architecture has a tested recovery path and priced exit plan.Stop treating ambiguity as capability.
- A diagram shows apps but not the system of record for each object
- Automation success is measured by runs rather than correct business outcomes
- A connector is authorized through one employee account with no continuity plan
- No one owns retries, duplicates, expired credentials, or vendor API changes
- Custom logic writes directly to financial or customer records without a reconciliation queue
- Build cost excludes monitoring, security, regression testing, support, and eventual replacement
Baseline the system, then improve it.
- Critical handoffs per completed job
- Automation exceptions per 1,000 events
- Mean time to detect and resolve a failed handoff
- Records corrected or duplicated across systems
- Monthly technical ownership hours
- Core workflow changes blocked by the architecture
- Estimated cost and time to export or replace each layer