Systems and scope
Sometimes the problem is the website. Sometimes it is what happens after the request arrives. The first design decision is whether to configure an existing platform, connect systems, build a focused tool, or combine those paths.
Capability matrix
These are project areas, not fixed packages. A useful scope identifies the people, records, integrations, exceptions, and acceptance checks involved.
| System area | Useful when | Possible deliverables | Important boundary |
|---|---|---|---|
| Service website and intake | Visitors cannot tell whether the company serves the job, area, urgency, or project type. | Service architecture, urgency paths, request context, conversion tracking, accessible direct contact. | A website should not diagnose plumbing conditions or promise unavailable response times. |
| Request triage and dispatch | Urgent and routine work enters one queue, ownership is unclear, or staff retypes requests. | Routing rules, queue views, status ownership, exception handling, notifications, audit history. | The business defines priority and coverage; automation supports rather than invents those policies. |
| Estimate and approval flow | Project details, site context, approvals, and follow-up live in disconnected notes and inboxes. | Estimate context record, approval state, reminders, decision history, handoff to scheduling. | Custom software does not replace on-site judgment, contractual review, or accounting controls. |
| Technician workflow | Field staff cannot quickly find access, contact, history, scope, or closeout requirements. | Mobile-first job view, structured notes, media references, status updates, closeout checklist. | Design must fit real field conditions, permissions, and connectivity constraints. |
| System integration | CRM, field-service, calendar, website, accounting, or messaging records disagree. | Record map, API or webhook integration, reconciliation, retry logic, alerts, documentation. | Integration depends on vendor access and capabilities; unsupported behavior is identified before commitment. |
| Maintenance and follow-up | Open estimates, maintenance opportunities, and completed-work communication rely on memory. | Rule-based reminders, customer-preference controls, open-work queues, reporting, review-request timing. | Communication must respect consent, frequency, privacy, and the business's actual service policies. |
Build, configure, or connect?
The right choice depends on process fit, vendor capability, data ownership, risk, maintenance burden, and how much operational advantage is truly unique.
Choose configuration when the existing field-service or CRM product supports the required workflow and the gap is setup, permissions, data structure, or staff handoff.
Choose integration when each system does its job but information becomes late, duplicated, or inconsistent at the boundary.
Choose custom software when the workflow creates real advantage or no available product can responsibly represent it.
What shapes effort
Faith Forge Labs does not publish a menu price because access, record quality, integration limits, user roles, uptime expectations, data migration, and support requirements materially change the work.
A direct conversation can determine whether the next step is configuration, integration, a focused build, or no project at all.