Lead Intake

Lead intake covers the first two stages of the service journey: capturing a new service request and confirming that the associated customer account is active. By the end of this stage the lead has a unique identifier, an initial status, and a customer ready to engage.

Flow

How Leads Enter the Platform

Leads can be submitted through three channels:

• Webhook — An external CRM or system POSTs lead data directly to the platform’s inbound webhook endpoint. Used by vendors who manage their pipeline in a separate tool.
• Embeddable Form — A hosted form placed on the vendor’s website. The customer fills in their requirements and submits; the platform creates the lead automatically.
• Manual Entry — A CSM, SDM, or vendor user creates the lead directly inside the platform dashboard. Typically used for leads sourced via phone, email, or events. The create form guides selection as a cascade (see below).

All three methods produce the same lead record and go through the same downstream journey.

Where the lead came from — its source

Separately from the channel it arrived through, every lead records its source: the part of the business that raised it. There are twelve:

Each channel sets it in its own way:

• Manual entry — the create form’s Lead source select, Sales unless changed.
• Embeddable form — the form’s Lead source setting on the integrations settings tab, Sales unless an administrator picks another. Every lead the form creates carries it; a website visitor never chooses it.
• Webhook — an optional source field in the payload. Absent, or not one of the twelve, and the lead is still accepted, as Sales.

The source shows as a badge on every card of the Live Service Pipeline and in the Customer Service Journey header, and in the lead source column of the Forecast Service Revenue register. It does not change who owns the lead: every source is owned by Sales until the BRD is approved.

Who brought the customer in

Where a channel knows who acted, the new customer’s record keeps it, and their profile names it: manual entry records the CSM, SDM or vendor user who created the lead, and an administrator’s invitation records the administrator who sent it. The webhook and the embeddable form record nobody, which is the truth about them — an anonymous submission has no inviter to name, and the profile leaves the line out rather than guessing. Customers who joined before this was recorded have no inviter either; nothing was inferred backwards for them.

Details the public form wrote

A customer the embeddable form created carries whatever the visitor typed — company, region and country — and when the real person is later invited and signs in, they take over that record with those details still on it. Until someone confirms them, the person’s profile marks the company and location line Unconfirmed, with a note that the details came from the public form. A staff member (administrator, CSM or SDM) confirms them by saving the profile’s operational details, where the company can now be corrected or cleared alongside the region and country; the mark is gone from that save on. A save the form rejects confirms nothing.

Location inheritance

A lead records a region and a country, shown in the workspace header. When a lead names a customer and the channel supplies no region or country of its own — from any intake channel, webhook and embedded form included — the missing fields are inherited from the customer’s profile location. A value the channel does supply always wins, field by field; a customer without a location simply leaves the lead blank.

The inheritance is also retroactive. When a customer’s region or country is set or changed later, that customer’s location-less leads pick up the new value automatically — one activity entry per lead, recorded as a system change on the lead trail. Leads that already carry their own region and country are never touched.

Guided product → service → skill selection

The manual create form captures the request as a dependent cascade. The user picks a product first; the service list is then filtered to the services linked to that product; and an optional skills selection is filtered to the skills linked to the chosen service. Changing the product refilters services and clears the downstream choices.

When a product has no linked services yet — or a service no linked skills — the picker falls back to showing all active options, so a lead can always be created while the catalogue is still being linked up. The create action and the spreadsheet import both check that the chosen service belongs to the product (and skills to the service) whenever those links exist, keeping the captured product → service → skill path coherent. The lead still stores product, service, and skills[] in the same shape as before.

requestId

Every lead is assigned a sequential requestId (e.g. #1, #2, #3) at creation time. This is a human-readable identifier used in communications, the dashboard, and support. Each number is allocated atomically from a sequence held on the tenant, which guarantees uniqueness and sequential ordering within that tenant.

Status Initialisation

The lead’s initial status depends on whether the customer already has an active account:

Once a pending customer registers and logs in, the status advances to backlog and the lead moves forward. If the customer never responds, the lead is marked Abandoned.

Key Fields