One client picture
Keep call, form, message, qualification notes, booking activity, and next-step context connected.
Agency lead operations
Spacebrain connects inbound calls, forms, conversations, qualification, follow-up, booking, and client context—so the next action is clear before a lead goes cold.
A lead record is useful only when the team can see what happened, what should happen next, and who owns the handoff. Spacebrain is designed around that operating path.
Keep call, form, message, qualification notes, booking activity, and next-step context connected.
Route the initial conversation, follow-up, booking step, or human escalation using the rules your client actually needs.
Validate intake questions, escalation paths, booking rules, and CRM handoff before a workflow represents your agency.
The operating model
Calls, forms, and inbound conversations enter with the details available at first contact.
Ask the right initial questions, identify urgency, and choose the right next step.
Book, follow up, assign, or escalate without separating the action from the customer record.
Define the client workflow before launch.
Keep automation transparent and preserve a human route for exceptions.
Use client-facing intake and handoff rules that your team can review.
Before the CRM
Agency teams do not need another place to store contact records. They need a shared operating path that preserves context from first signal through follow-up, booking, handoff, and review.
When the call, form source, message, and client notes live in different places, the next response starts without the information that should guide it.
A record alone does not define who responds, what they need to collect, or when the lead should move to booking or a person.
A useful workflow carries the reason for the inquiry, relevant details, urgency, and next-step history into the appointment or handoff.
Visible states for contacted, qualified, booked, escalated, and unresolved leads let an agency improve a client delivery process responsibly.
AGENCY OPERATIONS GUIDE
An agency CRM is not differentiated by having more pipelines than a client can use. It is differentiated by whether a lead can move from first signal to a clear owner without losing the context that explains why the person contacted the business. When an agency manages lead response across several client accounts, the hard problem is not creating records. It is maintaining account separation, source context, ownership, service rules, and an auditable next action.
This guide describes an operating model for agencies that provide lead capture, qualification, booking, and CRM delivery. It is not a promise that automation replaces a client’s sales, dispatch, or account-management judgment. Those human roles need explicit handoffs and review rules.
Before configuring a pipeline, document what the agency owns and what the client owns. The agency may own workflow design, routing logic, dashboards, QA, and escalation reporting. A client may own sales calls, appointment attendance, quote approval, support, or dispatch. Confusion at this boundary creates the familiar failure mode where a lead exists in the CRM but no one believes they are responsible for it.
Write these boundaries into an account launch record. A CRM can make ownership visible, but it cannot decide a commercial agreement that has never been made.
Every agency account needs a minimum record structure. Start with the information that changes routing or follow-up decisions, rather than collecting every possible field. A practical contact and opportunity record should answer: which client owns this contact; how did the lead arrive; what did they ask for; which service or location applies; what stage is the conversation in; who currently owns it; and what next action is due.
Keep account identity separate from lead source. “Google Ads” is not an owner; “Client A – plumbing” is not a lead source. When these dimensions are mixed together, agencies cannot tell whether a delay originated in acquisition, a workflow, a sales queue, or an incorrect client configuration. Preserve timestamps for meaningful events such as capture, first owned action, booking, handoff, and closed outcome. These are operational facts a team can review without inventing a performance story.
Pipeline names should describe an observable state. “New inbound” means a signal has been captured but not assessed. “Awaiting qualification” means the agency or client needs a defined detail before choosing a route. “Ready for client action” means the record has enough context and a named client owner. “Booked” means an appointment exists, not that a sale happened. “Closed not a fit” should record why, so the agency can identify routing or offer mismatches.
Avoid stages such as “hot,” “working,” or “follow up” unless the team agrees on the evidence that moves a record there and the action that must follow. A stage without a next-action standard becomes a parking lot. For each stage, define the entry condition, required fields, owner, maximum time before review, exit condition, and fallback route.
For each lead type, write who receives it, who is the backup, how they are notified, and what happens when no action occurs. Do this for new enquiries, returning customers, reschedule requests, unsupported services, urgent requests, and leads outside a client’s service area. The matrix prevents an agency from depending on a generic notification sent to several people.
Use the same matrix in onboarding, QA, and client reviews. That makes delivery repeatable without forcing one client’s business rules onto another.
Multi-account delivery needs clear data boundaries. Each client should have distinct users, permissions, routing destinations, calendar rules, templates, reporting views, and knowledge sources where appropriate. An agency operator may need a cross-account view for QA, but a client should not see another client’s contact data or workflow configuration. Test account access with the role that will actually use it, not only as an administrator.
Separation also applies to messaging. A message should identify the client business accurately, use that client’s approved language, and route replies to the account’s correct queue. Reusing an agency-wide template can save time during setup, but it must be reviewed for client-specific services, hours, escalation contacts, consent, and regional requirements before activation.
Run realistic test leads before traffic is sent to a new account. Create tests from a new number, a known contact, an after-hours caller, an urgent request, an unsupported request, a web form, and a booking attempt. Confirm the source is preserved, the record appears in the correct account, the correct owner receives context, the expected due time is visible, and the conversation follows the intended route. Test what happens when no owner responds as well as the happy path.
For booking flows, verify calendar type, availability, timezone, confirmation, context transfer, and cancellation or reschedule handling. For qualification flows, verify that a caller can reach a person when their question does not match the configured paths. For integrations, record the system of record for each field so agency and client teams do not edit conflicting data in two places.
A weekly review should inspect unresolved and incorrectly routed work before it becomes a reporting exercise. Look for records with no owner, overdue next actions, duplicate contacts, incomplete qualification, booked appointments lacking context, frequent exceptions, and recurring reasons a lead was not a fit. Review examples alongside counts. A high volume of activity can still hide a workflow that confuses callers or creates unowned work.
Use findings to change one clear component at a time: an intake question, routing condition, message, owner assignment, calendar rule, or escalation path. Retest the affected scenario after each change. This preserves an evidence trail for the agency and prevents vague claims about “optimisation” from replacing observable operational improvement.
This model is a strong fit for agencies that have repeatable service categories, agreed client owners, a need to prove delivery quality, and a willingness to review exceptions. It is a weak fit when a client will not define ownership, needs every request decided by a senior person without a handoff rule, or expects a CRM workflow to resolve legal, safety, dispatch, or sales decisions automatically. In those cases, simplify the workflow and establish human review before expanding automation.
Use the AI receptionist setup and QA checklist to test the account model before launch. For a workflow-oriented view of lost inbound demand, see Missed Call Recovery. When ready to connect the operating model, start in Spacebrain.
A multi-client CRM should be treated as a delivery system. Before adding channels, users, or more automation, test whether the existing account produces an understandable record and an accountable next action. The scorecard below helps agencies distinguish a configured account from an operationally ready account.
Open a contact, opportunity, conversation, task, booking, and report as an operator and as a client user. In each location, confirm that the client account, location, relevant service, source, current owner, and current state can be understood without relying on memory. This is especially important for agencies that reuse a common delivery shell. The shell can be standard; the operational identity must remain specific to the client.
Test a lead that arrives through every active source. A form, missed call, calendar booking, referral, paid campaign, and manual record may need different source labels, but they should resolve into one coherent account view. If a team cannot identify the origin of a record, it cannot reliably diagnose whether a problem belongs to acquisition, routing, sales response, or reporting.
Do not test only as the agency administrator. Use a client sales-user role, an account-manager role, and a support or operations role where relevant. Confirm each role can see the work it owns and cannot see another client’s contacts, messages, configuration, or reporting. Confirm that a reassigned owner inherits the context needed to act, and that an unavailable primary owner triggers the agreed backup route rather than leaving the record in an unattended queue.
Ownership should be verifiable on individual records. A client should be able to answer: “Who needs to do something next, what are they expected to do, and by when?” If the answer is “the team,” the process is not sufficiently owned.
Review every stage definition with the people who will use it. For each stage, document the evidence that permits entry, the fields that must be present, the owner, and the next action. “Booked” should mean an appointment exists; “qualified” should mean the agreed qualification conditions were met; “closed” should not conceal whether the record was won, not a fit, unreachable, duplicate, or outside service area. These distinctions make account reviews useful without implying that a stage proves commercial performance.
Create a small exception queue for ambiguous records. That is usually safer than forcing an uncertain conversation into a sales or booking path. The agency can then review why the exception occurred and decide whether to change a question, rule, knowledge source, owner matrix, or human handoff.
Run a test pack that includes a caller who needs urgent help, a returning customer, a prospect outside the service area, a duplicate contact, a partially completed form, a reschedule request, and an unfamiliar question. For each test, inspect the initial record, routing, owner notification, due time, human escalation, final state, and audit trail. Test the outcome when the assigned owner does nothing. A workflow that works only when every person reacts immediately is not a reliable delivery process.
For appointment routes, verify that context travels with the booking: service requested, relevant answers, source, location, client account, and any stated limitation. A meeting should not force a caller to repeat the information that qualified the booking. When a booking is unsuitable, make sure the team can record the reason and route it to the right owner rather than treating it as a failed automation statistic.
Review a representative sample plus all records that are unassigned, overdue, incorrectly routed, duplicated, missing context, or unresolved. Ask what changed the outcome: a source label, message, qualification question, calendar rule, ownership gap, or client-side response process. Change one clear component, document why, and retest the relevant scenario. This review loop is how an agency demonstrates disciplined delivery without inventing ROI or conversion claims.
Release or expand an account only when the agency and client can demonstrate client separation, visible ownership, working handoffs, realistic exception paths, and a review routine. Use the Missed Call Recovery workflow guide for inbound-call scenarios and the AI receptionist setup and QA checklist for an implementation test pack. When the model is ready to connect, start in Spacebrain.
Keep a short release note whenever an agency changes a routing rule, owner, calendar path, message, integration, or permission model. Record the account, reason, affected scenario, expected behaviour, reviewer, and retest date. This prevents a later client question from becoming a search through disconnected messages, and makes it possible to reverse a change that created an unintended handoff.
Also distinguish a configuration assumption from an observed result. “New enquiries from this form should route to the estimator queue” is an implementation requirement. “The estimator accepted the handoff in the test scenario” is a QA result. Keeping them separate helps the agency communicate clearly, protect client expectations, and improve the operating model with evidence instead of broad claims.
Start with a connected workflow that your agency can review, improve, and deliver consistently.
Start for free