PUZINSKI / ORIGINAL SAMPLE
Fictional automation scope. No client systems, records, or results are represented.

WORKFLOW: Website inquiry to a responsible owner

PROBLEM
The next action after a website inquiry needs a clear owner.

FIRST-RELEASE BOUNDARY
One form source, one existing CRM, one assignment rule, and one notification or follow-up. Additional channels, migrations, or a conversational AI agent are outside this example.

TRIGGER
An accepted form submission becomes available for processing.

AGREED ACTIONS
1. Check that required fields are present.
2. Check the agreed duplicate key before creating a record.
3. Create or update the CRM record under the documented rule.
4. Assign the owner and create the agreed next action.
5. Make failures visible to the named process owner.

AI DECISION
This example can use straightforward rules. If an AI task is later useful, define its allowed information, permitted actions, output review, and human handoff before implementation.

EXCEPTIONS
Missing information -> hold for review.
Duplicate -> follow the agreed update rule; avoid duplicate notifications.
Unavailable CRM -> record the failure and use the agreed retry/recovery process.
No matching owner -> assign the agreed fallback owner.
Permission issue -> stop the affected action and alert the process owner.

ACCEPTANCE TESTS
Complete fictional inquiry reaches the agreed owner.
Missing required information does not create an unusable record.
The same event does not create two leads.
A failed action is visible and can be investigated.
The team can find the record, status, and next action.

HANDOVER
Workflow map, field mapping, test notes, known limitations, account ownership, operating instructions, and issue-reporting route.

RUNNING COSTS & CARE
Identify CRM, messaging, automation, and AI/API fees separately. Define monitoring, support windows, and change requests before relying on a real deployment.

This is a planning sample, not a running integration. Actual scope and fees require a separate signed proposal.