Custom Workflow AI Architecture — Example: Website Inquiry Intake

About this example

This is an anonymized example from a real client architecture delivered to a residential mortgage brokerage. The workflow shown here was approved, subsequently built, and has been in daily production since April 2026.

The full client engagement covered eight connected workflows and was scoped separately as a larger project. This document shows one of those workflows, Website Inquiry Intake, as a real-life example of the structure, level of analysis, workflow decisions, specifications, validation plan and implementation roadmap included in a $2,500 Custom Workflow AI Architecture.

Your document follows this same structure and depth, built around your workflow and your industry.

What has been removed. Client and staff names, customer data, priority criteria, response-time standards, message content, prompts, vendor configuration and performance figures. Where a client-set value would appear, it is marked [Redacted].

What the $2,500 package includes. One agreed workflow, one discovery session, one draft review, one revision round and the final architecture document. Building the workflow is a separate service; this client's system was built after the architecture was approved.

Executive summary

Every website inquiry becomes one owned CRM record with a next action and a measured response clock. AI recommends the next internal step; a loan officer decides and makes contact.

This document defines how the Website Inquiry Intake workflow operates today, where it breaks down, how it should operate, which steps belong to people, automation and AI, and how a qualified team should build and test it. It is an architecture, not a deployed system, legal advice or a guarantee of business results.

Client decision summary

The problem. Website inquiries depend on inbox visibility, informal handoffs and individual memory. That causes delayed outreach, unclear ownership, missed follow-up and no reliable way to measure response.

The decision. Every website inquiry creates or updates one CRM record, gets an accountable owner, starts a response clock, and carries a required next action and due date.

What automation does. Creates and matches records, records consent, assigns owners, creates follow-up tasks, tracks deadlines, escalates overdue work and applies communication eligibility rules.

What AI does. Supports the loan officer with internal next-step recommendations. It does not contact customers, give mortgage advice, judge eligibility, make lending decisions, override opt-outs or send messages.

What people do. Loan officers contact customers, confirm one-off outreach, give mortgage guidance, review eligibility, make lending decisions and record outcomes.

What must happen before build. The business approves form fields, consent language, routing and matching rules, response standards, message templates, system access, technology choices and escalation thresholds.

What success looks like. Every website inquiry has an accountable owner, a due next action, a measurable response clock, and a visible record in the CRM. No inquiry depends on an inbox, forwarded email, or one person's memory.

Workflow in scope

Architecture objective

The workflow must:

• Create or update one CRM record for every form submission, with source history preserved.
• Record SMS and email consent from the form as evidence, separate from any mortgage question.
• Assign one accountable loan officer and start the response clock.
• Give every active lead a visible next action and due date in the loan officer's daily queue.
• Release automated acknowledgments only through the communication control gate.
• Use AI only to recommend an internal next step, confirmed by a person before customer-specific contact.
• Keep working when the AI service, an integration or a person is unavailable.
• Escalate overdue, unowned or unconfirmed work to the supervising broker.

Automation and AI never give mortgage advice, determine mortgage eligibility, make lending decisions, or send a customer message on their own.

1. Current-state workflow

Today a website inquiry becomes an email in the broker's inbox, and follow-up depends on someone noticing it, forwarding it and remembering the next step.

1.1 How the work happens today

A prospect submits the form on the company website. The website emails the details (name, phone number and reason for contact) to the broker. The same information sits in the website backend, but staff do not use it to manage leads.

The broker or a team member reads the email and shares the lead with a loan officer, by forwarding it or in conversation. The loan officer calls when available. Call attempts, notes and future callback dates live in personal notes, calendars or memory.

If the prospect asks to be called back in six months, that commitment exists only with one loan officer. If that person is busy, or leaves the company, the callback can be missed entirely.

1.3 Current-state task inventory

1.4 Bottleneck analysis

1.5 Baseline measures

None of these measures were tracked before the redesign, so the architecture does not estimate them. The CRM becomes the measurement source, and baselines are set in the first reporting period after launch.

2. Future-state workflow

A form submission creates or updates one CRM record, assigns an owner, starts the response clock and puts a task in the loan officer's queue. AI recommends the next internal step; the loan officer decides and makes contact.

2.1 Ownership model

2.3 Task and handoff matrix

2.4 Decision rules

2.5 Ownership and escalation rules

All thresholds are client-set [Redacted].

3. Step-level specifications

Every significant step has a specification a builder can configure and test against. Two are shown in full here: form intake (WI-01) and the AI next-step recommendation (AI-01). The client document specifies every step in the same format.

Step WI-01: Website form intake and record creation

Owner: Website form and CRM · Purpose: turn every submission into one owned CRM record with no inbox handling · Entry: a prospect submits the form · Exit: the record exists (linked, new or in review), source and consent are recorded, an owner is assigned and a task is due.

Step AI-01: AI-assisted next-step recommendation

Owner: AI service connected to the CRM · Purpose: read what the loan officer records and highlight what matters, so the right next step happens without anyone re-reading every note · Entry: a new inquiry, a customer reply or a recorded conversation · Exit: a checked recommendation is saved on the record, or the workflow continues without one.

Example in production. A loan officer typed up a conversation with a borrower. The AI read the note, flagged the borrower as ready for follow-up and recommended the next step. The loan officer reviewed it and acted.

What runs without a person. Approved, pre-reviewed campaigns run automatically when a defined event or score change triggers them. A person confirms only one-off contact with a specific customer.

3.3 AI decision record

4. System architecture

The CRM is the system of record and the only place a customer message can be released. The LLM sits behind the integration layer and never touches a sending channel.

4.1 Components and tool recommendations

4.3 Data movement

Website lead

1. Prospect submits the form with approved disclosure and consent fields.
2. The website sends the submission event to the CRM.
3. The CRM applies matching rules and creates or updates the lead record.
4. The CRM records source, consent, preferences and per-channel eligibility.
5. The CRM assigns a loan officer and creates the follow-up task.
6. The communication control gate evaluates eligibility before any acknowledgment.
7. An eligible, approved email or SMS is sent through CRM automation.
8. Delivery, engagement, unsubscribe and workflow events return to the CRM.

AI recommendation

1. An approved CRM event sends an authenticated request to the integration layer.
2. The integration layer minimizes and validates the data, then calls the LLM.
3. The LLM returns a structured recommendation.
4. The integration layer validates it against the approved schema.
5. The CRM records the recommendation, source event, timestamp and status.
6. The CRM may create an approved internal task, reminder, priority input or review item.
7. The loan officer confirms the customer-contact path when required.
8. The gate evaluates eligibility before any approved automated message.

Replies and opt-outs. SMS replies, STOP and equivalent requests, and email unsubscribes return to the CRM through the integration layer. Opt-outs update suppression immediately and block that channel; replies route to the assigned loan officer's queue.

4.4 Storage and access requirements

4.5 Open validation items at design handoff

These were open when the architecture was delivered. All were resolved in the pre-build decision phase.

5. Validation and test plan

The workflow is ready for launch only when every case below produces its expected result, with evidence, or carries a documented and approved exception.

5.1 Test cases

LLM evaluation. Before release, recommendations are tested on approved sample records for schema validity, permitted inputs, no lending or advice content, correct routing of unclear cases to human review, and usefulness. The client sets the pass rate and sample size.

5.2 Risks and mitigations

5.3 Success measures

Baselines are set in the first reporting period after launch; targets are client-set [Redacted].

6. Implementation roadmap

Build the owned, measured human path first, add governed communication second, and add AI last, only once the workflow runs correctly without it.

6.1 Recommended build sequence

6.2 Pre-build dependencies

6.3 Launch readiness checklist

Every item below was confirmed before the April 2026 launch.

• [x] Form submissions reliably create or update CRM records
• [x] Consent evidence is stored per channel with disclosure version
• [x] Every new lead receives an owner, task, due date and running clock
• [x] Broker alerts fire for overdue, unowned and unconfirmed items
• [x] The communication control gate blocks ineligible and suppressed sends
• [x] AI output is validated, logged and confirmed; failures leave leads actionable
• [x] Loan officers, broker and administrators are trained for their roles
• [x] Support, change-control and metric owners are named

Sections 6.4–6.7 list what the client and the implementation partner must agree in writing before the build begins. These terms belong in the implementation agreement; this architecture identifies them so nothing is left open.

6.4 Implementation scope to be confirmed

Before implementation begins, the client and implementation partner will agree in writing which items are included in the build. The implementation scope may include CRM configuration, website form updates, workflow and routing configuration, integrations, communication controls, AI recommendation configuration, testing support, training, documentation, launch support, monitoring and post-launch support.

The architecture does not require all of these items to be included; the implementation partner prices only the items explicitly selected in the implementation statement of work.

Any item not explicitly included in the implementation statement of work is excluded from the build estimate.

6.5 Acceptance and user testing

The client will name a business owner responsible for user acceptance and a final production approver. The implementation partner will provide test evidence for the applicable Section 5 test cases.

Before launch, the client and implementation partner will agree on test users, test data, defect severity levels, the number of included re-test cycles, the process for accepting documented exceptions, and the criteria for production approval.

6.6 Build assumptions, access and exclusions

The implementation partner's estimate will state the required systems, environments, access, client inputs and timing assumptions. Unless specifically included, implementation excludes historical data migration or cleanup, website redesign, copywriting, legal or compliance advice, approval of disclosure language, paid software and messaging fees, work outside this workflow, and ongoing support after the agreed launch period.

6.7 Monitoring, training and handoff

The implementation statement of work will identify the monitoring and alert approach, alert recipients, operational owner, support period, reporting or dashboard deliverables, training format, documentation deliverables and handoff criteria.

Unless the implementation agreement states otherwise, ongoing monitoring, maintenance, optimization, vendor management and support after the agreed launch-support period are not included.

Final architecture decisions and handoff

Every decision a builder needs was either approved in this document or logged with an owner to approve before configuration.

A qualified implementation team can use this document to answer what starts the workflow, what data it needs, where the record lives, who owns each lead, what is due next, which steps follow rules, where people decide, what AI may and may not do, what happens when something fails, how it is tested and what must be built first.

Client next steps

In a client engagement, the business takes these steps after receiving the architecture:

1. Confirm that the scope, current-state findings and future-state design reflect how the business actually operates.
2. Approve, or assign an owner to, every open validation item in Section 4.5.
3. Confirm the final business decisions in the handoff table.
4. Share this document with the internal team, developer, agency or implementation partner building the workflow.
5. Require the implementation team to run the Section 5 test plan before launch.
6. Add AI-enabled steps only after the core workflow, records, tasks, routing and escalation work reliably.

Example from a real client engagement by Giosena. Client-identifying details, customer data, proprietary criteria, message content, prompts, configuration and performance figures have been removed or marked [Redacted].