Business workflows · Development case study
From customer enquiry to accountable follow-up
A modular SaaS architecture for turning scattered conversations into assigned work, visible follow-ups, and a connected customer history.
- Project context
- Enquiry and sales workflows for smaller businesses
- My role
- Solution architecture & hands-on .NET engineering
- Delivery stage
- Foundations implemented; pilot validation planned
01 / The business problem
The conversation starts.
The handoff gets lost.
Customer enquiries arrive through messaging, calls, and social channels. When staff manage them in separate chats, spreadsheets, and notebooks, lead ownership is unclear and follow-ups are easy to miss.
The initial product focus is a complete enquiry-to-follow-up workflow: capture a lead, assign responsibility, schedule the next action, and give the business owner a view of work still waiting.
Watch the workflow
From enquiry to reviewed response.
6-minute walkthrough · English captions. Playing loads YouTube's embedded player.
If the player asks you to sign in or cannot play, open the video on YouTube in a new tab.
02 / Designed workflow
Make the next action visible.
The proposed flow connects messaging, CRM, staff responsibility, and owner visibility. Pilot validation is part of the delivery plan.
Receive an enquiry
A customer contacts the business through messaging, web, phone, or another channel.
Create a lead
Connect the contact details, source, and conversation context to a structured record.
Assign ownership
Give the lead an accountable employee or team, manually or through a rule.
Schedule follow-up
Create a task, reminder, or response deadline for the next action.
Update the pipeline
Record progress through the business's sales stages.
Retain the activity
Keep notes, messages, appointments, and changes with the customer record.
Surface pending work
Show unattended leads, overdue actions, and pipeline movement to the owner.
Review the outcome
Use response time, conversion, and activity measures to evaluate the workflow.
- New
- Contacted
- Qualified
- Won or lost
Each tenant can configure its pipeline. A stage records progress; an assigned follow-up makes the next action explicit.
03 / Modular architecture
One business workflow.
Clear integration boundaries.
The target design combines business modules with shared tenant, identity, audit, and integration capabilities.
CRM & contacts
Customer records and relationships
Leads & pipeline
Ownership, stages and progress
Tasks & appointments
Next actions and scheduled follow-ups
Automation
Assignment and reminder rules
Analytics
Pipeline and activity visibility
Products & campaigns
Broader business context
Users
Workspace access and roles
Billing
Planned subscription boundaries
04 / Architectural reasoning
Keep the workflow focused.
Leave room to change.
The architecture supports a narrow first release while defining boundaries for later integrations and business modules.
Start with the enquiry lifecycle.
The delivery direction prioritizes a WhatsApp lead workflow and customer pilots before broad feature expansion. CRM, assignment, follow-up, and owner visibility form the initial focus.
Tradeoff Broader ERP capabilities wait until customer operations validate the core workflow.
Keep provider details at the edge.
Messaging and other external systems connect through adapters and APIs. The business domain is designed to remain independent of one messaging provider.
Engineering consideration Provider events and delivery states still need a clear translation into the application's customer records and workflow.
Separate progress from responsibility.
A pipeline stage describes the opportunity. Assignment and follow-up tasks identify who needs to act and when. Activity history keeps that work connected to the customer.
Engineering consideration Reassignment and stage changes need clear rules for any pending tasks and reminders.
Make configuration tenant-specific.
The design gives each business its own users, roles, branch and team structure, pipelines, and automation configuration.
Tradeoff Configuration adds flexibility, but every rule and administrative action must preserve the correct tenant boundary.
05 / Security & integrations
A workspace for each business.
Tenant, role, and permission inform authorization. External connections sit behind explicit integration boundaries.
Tenant workspace
- Business-specific users and roles
- Branches and teams
- Configurable pipelines and rules
- Data isolation and planned subscription boundaries
Security & history
- Authenticated access
- Role-based permissions
- Activity and change history
- Protected credentials and controlled administration
Integration design
- Messaging and social adapters
- Webhooks, email, and notifications
- Payment-provider boundaries
- Future accounting, ERP, and custom APIs
These are the documented integration and security boundaries. Individual provider connections and broader business integrations require staged delivery and validation.
06 / My contribution & delivery scope
A foundation for a focused pilot.
I defined the modular SaaS architecture, CRM and pipeline domains, tenant and authorization boundaries, automation concepts, and integration model.
Implemented foundation
Backend, experience & access
Developed .NET backend services, integrated Angular-based experiences, worked with PostgreSQL and relational models, implemented authentication and authorization, and built reusable platform capabilities.
Architecture & design
Workflows & platform boundaries
Designed REST APIs, application workflows, background processing, and cloud deployment patterns. Planned the subscription and configuration model around staged delivery.
Planned validation
Real enquiry operations
Prioritize customer pilots, review missed leads and follow-up activity, and validate the workflow before expanding into broader business modules.
.NET · C# · ASP.NET Core · REST APIs · Angular · TypeScript · PostgreSQL · Relational modelling · Modular SaaS · Tenant-aware authorization · Background processing
This study covers work in development. Conversion, response time, and follow-up activity are planned validation measures; customer results and paid-pilot outcomes are not yet reported.