Follow one lead through the workflow
A prospect fills in a form on your website. Here is what a workflow does with it.
- The form submission arrives with name, email, company, service of interest and a free-text message.
- The workflow checks the CRM for an existing contact with the same email or company.
- It checks consent and contact preferences before anything is sent.
- It applies your assignment rules, such as region, service line or account size.
- It reads the free-text message to spot urgency, an existing customer or a request that doesn't fit any service.
- It creates or updates the CRM record, assigns an owner and creates a task.
- Anything uncertain goes to a review queue instead of a guess.
Where a plain rule works and where AI helps
Most of a workflow should be ordinary rules. A rule is faster, cheaper and easier to check.
- Plain rule. Region to owner. A known email domain to an existing account. A consent field to a yes or no.
- Reading free text helps. "We spoke to Sarah last month about a renewal." "Urgent, our tracking broke after the site launch." "Do you work with healthcare companies?" A rule can't sort these reliably. A language model can suggest a category, and the workflow records how confident it is.
When the model isn't confident, the lead goes to a person. That is a design choice we make with you.
Inputs and decisions
Before we build, we map every input and every decision with you.
| Item | Example | Known or needs review |
|---|---|---|
| Source fields | Form fields, UTM parameters, landing page | Known |
| Duplicate check | Email, then company domain | Known, with a review rule for near matches |
| Customer preferences | Consent status, preferred contact method | Known, required before any message |
| Assignment rules | Region, service line, account size | Known |
| Message intent | Free text | Needs review when confidence is low |
When a workflow needs a person
Good automation is mostly about what happens when things go wrong. We test three cases on every build.
An ambiguous enquiry
The message mentions two services and a company that might be an existing customer. The workflow doesn't pick one. It creates the record, flags it and puts it in the review queue with its reasoning.
A failed write
The CRM rejects the update because a required field is missing. The workflow logs the error, keeps the original submission and tells the owner what is missing. Nothing is lost.
A retry
The CRM is unavailable for a few minutes. The workflow retries on a set schedule and stops after a set number of attempts. If it still fails, the owner gets an alert with the submission attached.
The owner sees every exception in one place, with the original data, what the workflow tried and what it needs from them.
What gets built
- The integration between your form, CRM and any other tools in the path.
- The rules and the AI steps, written down so your team can read them.
- Test cases, including the failure cases above, run before release.
- A review queue for exceptions.
- Run instructions covering a normal day, a paused workflow and a failed run.
Start small
You don't need to automate the whole process at once. A common first version handles the duplicate check and the assignment, and sends everything else to a person. Once your team trusts it, we add the next step.
Lead Nurture Engine in our build catalogue shows how the same approach extends to stage-based follow-up after the first assignment. It is a build concept, not a case study.
Not sure what the process should be?
If the problem is that nobody agrees who owns the next step, automation will only make the confusion faster. Agree on the process and its owner first. To see how a build is tested and handed over, read How we work.