Project 01 · End-to-end customer journey
Connecting a website visit to a booked call
A landing page and calendar are only the visible parts of the journey. Behind them, the business still needs to capture the right information, create the correct record, assign ownership, send timely communication, and know what happens if the prospect does not book or attend.
- Business type
- Founder-led professional service
- My role
- Journey design, front-end build, back-end configuration, testing
- Scope
- Inquiry through booked call
- Platforms
- HighLevel, calendar, email/SMS, Zapier
- Front-end deliverables
- Landing page, form, calendar, confirmation, reminders
- Back-end deliverables
- CRM record, pipeline, workflows, notifications, tasks
- Build type
- Solo build with client review checkpoints
- Confidentiality
- Client details redacted
What was not working
The prospect could submit a form or book a call, but the actions around that moment were not yet operating as one controlled journey.
The risk was not simply a missed email. Information could enter the wrong place, ownership could remain unclear, follow-up could depend on memory, and the business could lose visibility after the initial customer action.
Front-end experience
What the customer experienced
A clear page, focused call to action, relevant form questions, accessible booking options, immediate confirmation, timely reminders, and a defined path for rescheduling or missed appointments.
- Website or landing-page screenshot
- Form
- Calendar
- Confirmation page
- Email or reminder
- Mobile view
Back-end system
What happened behind the scenes
The submission created or updated the correct CRM record, entered the prospect into the appropriate pipeline stage, assigned ownership, triggered internal notifications, and started communication based on the prospect's actual status.
- CRM contact
- Pipeline
- Workflow
- Notification
- Task or assignment
- QA checklist
The connection
How the two sides connected
Submit↓Record
Book↓Confirm
Miss↓Recover
Attend↓Update
Decide↓Continue / close
Your role
What I owned
I mapped the journey, defined the records and handoffs, built the customer-facing path, configured the supporting workflows, tested the experience from both sides, and documented what the business needed to manage after handover.
Verification
How I checked the build
I tested the journey using the same actions a real prospect and team member would take, including duplicate submissions, incomplete information, rescheduling, missed appointments, ownership changes, and workflow stop conditions.
Duplicate submissionsIncomplete informationReschedulingMissed appointmentsOwnership changesWorkflow stop conditions
HighLevelPipelinesWorkflowsCalendarZapierEmail & SMS
Project 02 · Internal and client operations
Creating one operational home for internal and client work
Internal tasks and client work lived in different systems or scattered spreadsheets. It was difficult to see project status, work in progress, or who was responsible for the next step.
- Business type
- Agency / studio operations
- My role
- Operations design, workspace build, SOP documentation
- Scope
- Internal operations and client delivery
- Platforms
- ClickUp, documentation tools, templates
- Front-end deliverables
- Client workspace, intake forms, status views
- Back-end deliverables
- Task structures, ownership rules, QA checkpoints, SOPs
- Build type
- Solo build with team review
- Confidentiality
- Client details redacted
What was not working
Internal tasks and client work lived in different systems or scattered spreadsheets. It was difficult to see project status, work in progress, or who was responsible for the next step. This made planning hard and could delay delivery.
Front-end experience
What the client saw
A single, structured client workspace with clear stages, visible progress, and defined approval points — replacing scattered email threads and ad-hoc updates.
- Client workspace view
- Status and stage labels
- Approval requests
- Deliverable previews
Back-end system
What happened behind the scenes
Standard structures for internal and client work, with clear task ownership, status stages, templates, SOPs, and review checkpoints. This included a full client workspace and an internal system for recurring tasks and approvals.
- Task structures
- Ownership rules
- QA checklists
- Recurring workflows
The connection
How the two sides connected
Brief↓Intake task
Approval↓Stage move
Production↓Owner + deadline
QA↓Checklist pass
Delivery↓Close + review
Your role
What I owned
I designed the operational structure, built the client and internal workspaces, documented the SOPs and QA checkpoints, and tested the flow from brief intake through delivery close.
Verification
How I checked the build
I ran a representative project through the full structure, including approval delays, owner changes, and QA failures, to confirm the system surfaced what was waiting and who owned the next step.
Approval delayOwner changeQA failure pathRecurring task cycle
ClickUpSOPsQA checklistsTemplatesEscalation paths
Project 03 · Knowledge to documented system
Turning business knowledge into a usable operations manual
Important processes, requirements, and decisions existed mainly in the owner's head or in scattered documents. Onboarding was slow, quality was inconsistent, and important details were missed or forgotten.
- Business type
- Founder-led service business
- My role
- Process mapping, documentation, training design
- Scope
- Core business processes
- Platforms
- Documentation and mapping tools
- Front-end deliverables
- Training guides, process references, onboarding paths
- Back-end deliverables
- Process maps, ownership rules, exception documentation
- Build type
- Solo build with owner collaboration
- Confidentiality
- Client details redacted
What was not working
Important processes, requirements, and decisions existed mainly in the owner's head or in scattered documents. Onboarding was slow, quality was inconsistent, and important details were missed or forgotten.
Front-end experience
What the team used
A structured operations manual documenting core processes, ownership, exceptions, and expected outcomes — built as the reference point for training, onboarding, quality control, and systemisation.
- Process reference guides
- Onboarding paths
- Training checklists
- Exception examples
Back-end system
What happened behind the scenes
Each process was mapped, tested with a real scenario, and refined before being documented. Ownership was assigned per stage, and decision rules and exceptions were captured in plain operational language.
- Process maps
- Ownership rules
- Decision rules
- Exception documentation
The connection
How the two sides connected
Knowledge↓Process map
Decision↓Owner + rule
Scenario↓Tested step
Refinement↓Documented guide
Handover↓Shared source of truth
Your role
What I owned
I mapped the processes, identified decision rules and exceptions, tested each stage with a real scenario, documented the system in plain language, and prepared the manual for training and onboarding use.
Verification
How I checked the build
I tested each documented process with a real scenario, including exceptions and edge cases, before finalising the manual. The goal was a reference the team could actually use, not a document that looked complete on paper.
Real-scenario testException pathOwner handoffOnboarding walkthrough
Process mappingDocumentationTraining guidesOwnership rules
Rica Ragonjan