Capture the request.
The website collects the minimum useful information first, then adds trade, service, urgency, source, and qualification fields as the customer commits.
Relay 1.0 technical specs
The wiring behind Service Lab intake.
Relay connects the site, the funnel, the database, alerts, and the CRM into one system. Every lead is stored first. Everything else runs from that record.
Record firstThe lead is saved before any third-party CRM API is called.
Route secondNotifications and CRM writes run from the same database event.
Maintain alwaysAPI changes, retries, auth, and monitoring stay with Service Lab.
◆ System order
The database is not backup. It is the spine.
Relay does not depend on a CRM write to decide whether a lead exists. The lead exists once it is recorded in the Service Lab database. That design keeps outages, rate limits, expired tokens, and vendor API changes from becoming lost leads.
Write the lead record.
Relay creates the durable record with contact data, job details, form path, attribution, timestamp, routing state, and delivery status. Sensitive fields are stored behind database access controls, not sent through spreadsheets or inbox chains.
Trigger alerts from the record.
SMS and email alerts fire from the database event. If a CRM is slow or unavailable, the owner still gets the lead and can call the customer back.
Normalize and route to the CRM.
Relay maps the internal lead model into each CRM's required format, then creates or updates the contact, customer, lead, job request, or estimate object.
Retry and monitor failures.
Failed writes stay attached to the lead as status, error detail, and retry state. The failure is visible to Service Lab and fixable without asking the client to rebuild a Zap or retype every field.
◆ Runtime architecture
One internal model. Different CRM adapters.
Every CRM has its own field names, auth model, API shape, object hierarchy, and rate limits. Relay keeps the lead model stable, then uses adapters to speak the right language for each destination.
relay.pipelinelive
Intake API
Validate and sanitizeRequired fields, spam checks, structured job details, source metadata.
Database
Persist lead firstEncrypted platform storage, scoped access, audit-friendly status fields.
Worker queue
Fan out from recordSMS, email, CRM sync, retry policy, failure state.
Adapters
REST, GraphQL, MCPCRM-specific clients and MCP servers when a tool exposes actions through that interface.
Monitoring
Watch the handoffDelivery state, API errors, token health, and integration maintenance.
REST when the CRM is resource-based.
Most field service CRMs expose contacts, customers, jobs, and requests as REST resources. Relay uses authenticated API clients, scoped credentials, and per-CRM field mapping.
GraphQL when the CRM exposes typed operations.
For platforms with GraphQL APIs, Relay can request exactly the fields required, combine related writes, and keep integration code aligned to the provider's schema.
MCP servers where actions are tool-driven.
For systems that publish business actions through MCP, Relay can call those tools as a controlled integration layer instead of scraping screens or relying on brittle browser automation.
◆ CRM coverage
We reinforce the software you already run.
Relay does not ask an owner to switch systems. If a CRM is supported, we route into it. If it is not supported yet, the lead database still gives the team a working intake record on day one.
Jobber
Contacts, client records, requests, jobs, or notes mapped to the account's intake workflow.
CurrentServiceM8
Lead details normalized into customer and job structures with status tracking.
CurrentService Fusion
Customer and job-request routing through the API shape available to the client account.
CurrentKickserv
Contact and opportunity data mapped into the existing dispatch or sales workflow.
CurrentGorillaDesk
Customer and service details routed for pest control and recurring-service intake.
CurrentComing soon
Housecall Pro, ServiceTitan, and JobNimbus are planned as larger-account integrations.
Planned◆ Storage and security
Lead data is stored before it moves.
A lead is operational data: name, phone, email, service need, location, source, urgency, and notes. Relay treats that as the system of record for intake.
Controlled database access
Lead records live in a database with application-level access controls. CRM credentials, routing rules, and delivery states are not exposed to public forms.
Encrypted platform storage
Production database providers encrypt data at rest and in transit. Relay is designed around those managed controls instead of passing lead data through ad hoc documents.
Scoped CRM credentials
Each CRM connection uses the provider-supported authentication path available for that platform, typically OAuth or API tokens with the narrowest practical access.
Failure state attached to the lead
If the CRM write fails, the lead record remains intact with the error state. The team can still call, and Service Lab can repair the integration.
◆ Customer questions
What happens if my CRM is down?
The lead is already stored. SMS and email still fire from the database record, and the CRM write can be retried later.
Does Relay replace my CRM?
No. Relay sits before the CRM. It captures, stores, routes, and monitors intake so the CRM receives cleaner data faster.
What if my CRM has weird required fields?
Those fields are handled in the CRM adapter. Relay maps its internal lead model to the fields your account requires.
Can engineers inspect how it works?
Yes. The architecture is intentionally simple: intake endpoint, database record, worker queue, CRM adapter, notifications, monitoring.
Do you use Zapier?
Not as the core reliability layer. Relay is built around first-party database records and maintained integrations, not a chain that fails silently.
What data do you send to the CRM?
The fields needed to create the right operational record: contact info, job type, urgency, location, notes, source, and qualification metadata.
Can we keep our current website?
Yes. Relay can be wired behind a rebuilt top-of-funnel layer or a new Service Lab site, depending on what the business needs.
Who maintains API changes?
Service Lab does. CRM API changes, token issues, field mapping updates, and retry handling are part of the system staying live.
◆ Next step