“
Brought ideas to life and kept the design at the forefront.
Business Owner, Gateway Gamers
Design & Client Work PROJECT 01 / HUBSPOT CRM
Outbound Segmentation + Suppression
A simulated HubSpot CRM project focused on targeting accuracy, suppression governance, lifecycle hygiene, follow-up workflows, and consistent outbound reporting.
Project Overview
PlatformHubSpot CRM
TargetingSegmented Views
SuppressionMaster DNC
ReportingKPI Definitions
Goal
Build a governed outbound segmentation system for community banks and credit unions that prevents accidental outreach to suppressed records while keeping follow-up activity and KPI reporting consistent.
Workflow
01
Define the outbound pool
Eligible contacts require a known email address, outbound eligibility, and a lifecycle stage other than Customer.
02
Create targeted segments
Persona and institution-type views separate community-bank and credit-union contacts for more relevant outreach.
03
Apply master suppression
A shared Do Not Contact rule removes customers from the outbound pool and all related targeting views.
04
Connect execution to reporting
Outbound status and last-touch properties feed follow-up queues and attempted, connected, and meeting-set KPI views.
Data Model + Governance
Required Fields Persona, institution type, outbound eligible, lifecycle stage, outbound status, and last outbound touch
Suppression Rule Lifecycle Stage = Customer is excluded from the outbound pool and all targeting segments
Status Definitions Not Started, Attempted Outreach, Connected, Meeting Set, Nurture, and Disqualified
Naming Conventions OUT | Pool | …, OUT | Persona | …, OUT | Institution | …, and SUP | Master | …
Tools Demonstrated
HubSpot ContactsCustom PropertiesAdvanced FiltersLifecycle StagesSuppression RulesCRM Views
Project Evidence
The screenshots show the governed outbound pool, master suppression logic, and a targeted credit-union segment.
Reporting Structure
REP VIEW
Persona and institution segments with follow-up-needed and overdue queues.
MANAGER VIEW
Attempts, connects, meetings set, and weekly activity snapshots.
DEFINITIONS
Shared KPI definitions for attempted, connected, and meeting-set outcomes.
Outcome
TargetingStandardized
Reusable outbound pool plus persona and institution segments.
SuppressionEnforced
Customers excluded through shared master DNC logic.
Reporting HygieneImproved
Status and date properties support consistent follow-up and KPI views.
Portfolio Note
This is a simulated HubSpot sandbox project created to demonstrate CRM segmentation, suppression governance, lifecycle hygiene, and reporting logic.
PROJECT 03 / HUBSPOT CRM
KPI Dashboard Pack
A simulated HubSpot reporting project focused on governed KPI definitions, date-property hygiene, weekly activity visibility, and consistent manager reporting.
Project Overview
KPI ConsistencyDefined
Weekly ActivityTracked
Meeting KPIDated
Follow-Up CoverageVisible
Goal
Create a lightweight KPI reporting pack inside HubSpot that standardizes what counts as outreach progress and produces consistent weekly snapshots for rep and manager visibility.
Reporting Workflow
01
Standardize outcomes
Use Outbound Status to define attempted outreach, connected, meeting set, nurture, and disqualified outcomes.
02
Timestamp results
Use Last Outbound Touch for recency and Meeting Set Date for meeting KPI tracking.
03
Build rep KPI views
Views show current pipeline activity by attempted outreach, connected contacts, and meetings set.
04
Create the manager snapshot
The Weekly Activity view summarizes outreach momentum and supports quick performance monitoring.
Data Model + Reporting Rules
Core Properties Outbound Status, Last Outbound Touch, and Meeting Set Date
KPI Definitions Attempted, connected, and meeting-set outcomes are defined consistently across views.
Suppression Awareness KPI views exclude customers to reduce inflated outbound activity counts.
Date Filters Eligible contacts are combined with consistent date windows such as today and this week.
Tools Demonstrated
HubSpot PropertiesAdvanced FiltersCRM ViewsKPI DefinitionsDate PropertiesActivity Reporting
Project Evidence
The screenshots show the meeting-set KPI view, connected-contact reporting, and weekly manager activity snapshot.
Reporting Structure
REP KPIs
Attempted outreach, connected, meetings set, and disqualified contact views.
MANAGER VIEW
Weekly activity snapshot using Outbound Status and Last Outbound Touch.
DEFINITIONS
Shared KPI definitions and SLA rules keep reporting consistent across views.
Outcome
Reporting ConsistencyStandardized
Attempted, connected, and meeting-set outcomes use aligned definitions.
Meeting KPIOperational
Meeting Set Date supports week-based meeting tracking.
Manager VisibilityImproved
Weekly Activity provides a faster snapshot of outreach and pipeline health.
Portfolio Note
This is a simulated HubSpot sandbox project created to demonstrate KPI standardization, activity hygiene, reporting views, and manager visibility.
PROJECT 04 / HUBSPOT SERVICE HUB
Ticket Resolution Project
A simulated support workflow demonstrating ticket intake, troubleshooting, customer communication, documentation, root-cause identification, and ticket closure.
Project Overview
Issue TypeAccount Access
PriorityHigh
SourceEmail
Final StatusClosed
Support Scenario
Create a realistic HubSpot support ticket showing how an account-access issue can be documented, investigated, communicated, and resolved within a single customer record.
Resolution Workflow
01
Document the issue
Created the ticket with a clear description, customer association, ticket owner, source, priority, and initial status.
02
Investigate the cause
Confirmed the password-reset email was delivered and identified the login method as the likely source of the problem.
03
Communicate with the customer
Sent a follow-up email asking whether the customer was using the organization’s SSO portal or the standard direct login page.
04
Resolve and close
Provided the correct SSO login path, documented successful access, recorded the root cause, and closed the ticket.
Ticket Data + Documentation
Core Properties Ticket name, pipeline, status, description, source, owner, priority, and create date
Internal Documentation Troubleshooting observations, customer findings, root cause, and final resolution
Customer Communication Logged email requesting the information needed to isolate the login problem
Resolution Record Closed status with a final note confirming restored access and no further action required
Tools Demonstrated
HubSpot TicketsTicket PropertiesActivity TimelineInternal NotesCustomer EmailTicket Closure
Project Evidence
The screenshots show the ticket progressing from structured intake through troubleshooting, communication, and final closure.
Support Record Created
INTAKE
Issue description, customer association, owner, source, priority, and ticket status.
ACTIVITY
Internal troubleshooting notes and a customer-facing follow-up email.
RESOLUTION
Confirmed root cause, restored customer access, and documented ticket closure.
Outcome
Ticket HistoryComplete
The full support process remains visible within one customer record.
Root CauseDocumented
The issue was traced to the customer using the incorrect login path.
Customer OutcomeAccess Restored
The customer successfully signed in through the correct SSO portal.
Portfolio Note
This is a simulated support scenario created in a HubSpot sandbox to demonstrate ticket-management, troubleshooting, documentation, and customer-support workflow skills.
PROJECT 05 / HUBSPOT SERVICE HUB
Knowledge Base Project
A simulated Service Hub knowledge-management project focused on clear technical writing, searchable content, reusable support documentation, and customer self-service.
Project Overview
Article TypeHow-To Guide
AudienceEnd Users
Issue CategoryAccount Access
Support ModelSelf-Service
Support Scenario
Create a clear self-service knowledge base resource for a recurring account-access issue so customers can locate the correct login instructions, understand common causes, and complete basic troubleshooting before contacting support.
Documentation Workflow
01
Identify the recurring issue
Selected an account-access problem that customers may be able to resolve without direct agent assistance.
02
Structure the article
Organized the content with a clear title, short introduction, ordered instructions, troubleshooting notes, and next steps.
03
Improve readability
Used concise headings, short paragraphs, numbered actions, and plain-language explanations designed for quick scanning.
04
Support content discovery
Assigned the article to a relevant category and used searchable wording that matches how customers describe the issue.
Article Structure + Governance
Article Title Uses customer-facing language that clearly describes the issue being solved.
Content Structure Introduction, prerequisites, ordered steps, troubleshooting notes, and escalation guidance.
Searchability Uses relevant account-access, password-reset, login, and SSO terminology.
Maintenance Designed so support teams can update instructions when login procedures or system behavior changes.
Tools Demonstrated
HubSpot Knowledge BaseArticle EditorContent StructureTechnical WritingCategoriesSearch Optimization
Project Evidence
The screenshots show the published resource, article structure, and the editing and discovery experience used to manage the content.
Support Content Created
ARTICLE
Customer-facing instructions for resolving a recurring account-access issue.
STRUCTURE
Clear headings, ordered steps, troubleshooting guidance, and escalation information.
DISCOVERY
Relevant category placement and searchable wording designed around customer terminology.
Outcome
DocumentationStandardized
A repeatable article structure supports consistent customer-facing guidance.
FindabilityImproved
Clear naming and categorization make support content easier for customers to locate.
Self-ServiceEnabled
Customers receive a reusable resource for resolving common account-access problems independently.
Portfolio Note
This is a simulated HubSpot sandbox project created to demonstrate knowledge management, technical writing, self-service support, and content-governance skills.
PROJECT 07 / HUBSPOT SERVICE HUB + SQLITE
Support Ticket Analysis with SQL
A simulated support-operations project that exports structured HubSpot ticket data into SQLite for triage analysis, workload reporting, priority sorting, and resolution-time measurement.
Project Overview
Source SystemHubSpot
DatabaseSQLite
Ticket Records6
Avg. Close Time57.45 min
Goal
Build a realistic support-analysis workflow that starts with structured HubSpot ticket records and continues into a SQL database where support teams can identify urgent work, summarize ticket distribution, and calculate operational metrics.
Data Workflow
01
Structure ticket data in HubSpot
Created support records with consistent fields for status, priority, source, issue category, description, ownership, create date, and close date.
02
Export and clean the records
Exported ticket data into CSV format, removed unrelated records, selected useful support fields, and converted column names into SQL-friendly formatting.
03
Build the SQLite database
Imported the cleaned CSV into DB Browser for SQLite as a structured table named support_tickets.
04
Query support operations
Used SQL to identify open work, prioritize urgent tickets, summarize workload, and calculate average close time.
SQL Analysis Performed
Open-Ticket Filtering Used WHERE conditions to isolate tickets that still required support-team attention.
Priority Sorting Used ORDER BY with CASE logic to organize open work from High to Medium to Low.
Workload Summaries Used COUNT and GROUP BY to summarize tickets by status, category, and priority.
Resolution Metrics Converted time values into numeric data and used AVG and ROUND to calculate a 57.45-minute average close time.
Tools Demonstrated
HubSpot TicketsCustom PropertiesCSV ExportSQLiteDB BrowserSQL QueriesData CleaningSupport Reporting
Project Evidence
The screenshots show the structured HubSpot ticket dataset, SQLite import, and SQL-generated priority queue.
SQL Queries Created
TRIAGE
Filtered open tickets and used CASE-based sorting to place high-priority support issues first.
VOLUME
Counted tickets by status, priority, and issue category using COUNT and GROUP BY.
TIMING
Converted resolution-duration values into numeric data and calculated average close time.
Outcome
Data StructureStandardized
Support records were organized into consistent fields suitable for database analysis and reporting.
Priority VisibilityImproved
Open support work can be filtered and ordered so urgent technical issues appear first.
Operational InsightQuery-Driven
SQL provides summaries of workload, status, issue categories, priorities, and close-time performance.
Portfolio Note
This is a simulated support-operations project created with HubSpot Service Hub, CSV data, SQLite, and DB Browser for SQLite. The records and scenarios were created for skills demonstration and do not represent production customer data.
PROJECT 06 / HUBSPOT SERVICE HUB
SLA + Support Dashboard Project
A simulated support-operations project focused on priority-based ticket queues, SLA monitoring, escalation logic, and centralized support-performance reporting.
Project Overview
Queue ModelPriority-Based
Timing ModelSLA-Driven
EscalationRule-Based
ReportingDashboard View
Support Scenario
Create a support-operations system that helps teams prioritize urgent work, identify overdue tickets, monitor response and resolution performance, and review recurring issue trends from a centralized dashboard.
Support Operations Workflow
01
Prioritize incoming tickets
Use ticket priority, status, create date, and ownership to identify urgent work and organize the support queue.
02
Track SLA performance
Monitor first-response timing, resolution timing, overdue status, and other service-performance indicators.
03
Escalate overdue work
Use escalation properties and queue views to surface tickets requiring faster follow-up or management attention.
04
Review support trends
Use dashboard views to monitor response time, resolution time, overdue work, workload, and recurring issue categories.
SLA Model + Governance
Priority Rules High-priority tickets receive faster response expectations and greater queue visibility.
SLA Properties First response time, resolution time, overdue status, priority, owner, and ticket status.
Escalation Logic Overdue or high-priority tickets are surfaced for follow-up and management review.
Reporting Standards Dashboard views use consistent definitions for response, resolution, overdue work, and recurring issue trends.
Tools Demonstrated
HubSpot TicketsTicket PipelinesSLA PropertiesPriority QueuesEscalation LogicSupport Dashboards
Project Evidence
The screenshots show the priority-based ticket queue, SLA and escalation configuration, and the support-performance dashboard.
Support Reporting Created
QUEUE
Priority, ownership, ticket status, age, and overdue work organized for faster triage.
SLA
First-response timing, resolution timing, overdue status, and escalation indicators.
DASHBOARD
Response time, resolution time, overdue tickets, issue trends, and support workload visibility.
Outcome
Queue VisibilityImproved
Priority and overdue work are easier for support teams to identify and manage.
SLA MonitoringOperational
Response and resolution timing can be reviewed through consistent ticket properties.
Performance ReportingCentralized
Support leaders receive a clearer view of workload, overdue work, and recurring issue trends.
Portfolio Note
This is a simulated HubSpot sandbox project created to demonstrate SLA management, support prioritization, escalation logic, and dashboard-reporting skills.
PROJECT 01 / HEALTHCARE SYSTEMS
Dragon Medical One Clinical Documentation Workflow
A simulated healthcare application-support project demonstrating foundational understanding of voice-driven clinical documentation, dictation workflows, reusable documentation tools, and common user-support scenarios.
Project Overview
EnvironmentSimulated Healthcare Workflow
PlatformDragon Medical One
Project TypeApplication Support
FocusClinical Documentation
Challenge
Clinical documentation applications need to support efficient documentation while allowing users to work accurately within their established healthcare workflows.
Application-support teams may also need to distinguish between microphone, audio, dictation, workflow, user-profile, and application-related issues when assisting clinicians.
Approach
Created a simulated Dragon Medical One workflow that follows a user from application readiness and microphone verification through dictation, documentation review, reusable text tools, and completion of the documentation process.
The project also documents common support scenarios and a structured troubleshooting path for identifying where an issue may be occurring before escalation.
Clinical Documentation Workflow
01
Verify application readiness
Confirm that the application, user session, microphone, and audio input are available before beginning documentation.
02
Begin voice documentation
Use voice dictation to enter clinical documentation into the appropriate supported documentation area.
03
Review and refine
Review recognized text and use supported voice or editing workflows to correct and refine documentation.
04
Complete the workflow
Verify the final documentation and return to the clinical application workflow with the documentation ready for the appropriate next step.
Core Concepts Explored
Voice Dictation Understanding the basic workflow for converting clinician speech into documentation within supported applications.
Microphone & Audio Readiness Checking microphone selection, audio availability, and basic device readiness when dictation is unavailable or inconsistent.
Reusable Documentation Exploring reusable text and voice-driven tools that can reduce repetitive documentation tasks.
Recognition & Correction Understanding the importance of reviewing recognized text and correcting documentation before completing the workflow.
Application Support Workflow
01Identify the Issue
Determine whether the reported problem involves access, microphone input, dictation behavior, recognition, or the documentation workflow.
02Verify the Environment
Check the active application session, selected audio device, basic connectivity, and the context in which the issue occurs.
03Isolate the Problem
Use structured testing to determine whether the issue follows the device, application, workflow, or user session.
04Document or Escalate
Record symptoms, troubleshooting performed, observed behavior, and relevant environment details before resolution or escalation.
Example Support Scenarios
SCENARIO 01 Microphone Not Detected
Verify device connection and microphone selection, confirm the device is available to the operating system, and determine whether the issue is isolated to Dragon Medical One.
SCENARIO 02 Dictation Is Not Appearing
Confirm the active documentation field and application context, verify that dictation is active, and test whether speech is recognized in another supported location.
SCENARIO 03 Recognition Needs Correction
Review the recognized text, determine whether the problem is isolated or recurring, and use the appropriate correction or editing workflow.
SCENARIO 04 Issue Requires Escalation
Capture the user impact, device and application context, troubleshooting already completed, and reproducible symptoms for the next support tier.
Project Evidence
Outcome
Workflow Documented Clinical dictation process
Support Process Structured Troubleshooting and escalation
Knowledge Level Foundational Application workflow familiarity
Skills Demonstrated
Dragon Medical One FundamentalsClinical Documentation WorkflowApplication TroubleshootingMicrophone & Audio SupportWorkflow AnalysisTechnical DocumentationIssue IsolationEscalation DocumentationEnd-User SupportHealthcare Application Concepts
Healthcare Systems Portfolio Note
This is an independent portfolio simulation created to demonstrate foundational knowledge of Dragon Medical One workflows and transferable application-support skills. It does not represent production clinical experience, administration of a live Dragon Medical One environment, or access to patient information or PHI.
PROJECT 01 / HEALTHCARE SYSTEMS
Oracle Health EHR Workflow
An independent healthcare systems project exploring Oracle Health Millennium FHIR R4 data, patient encounters, structured clinical records, and the application-support workflows used to inspect and understand healthcare information.
Project Overview
EnvironmentOracle Health Public Sandbox
PlatformOracle Health Millennium
StandardFHIR R4
FocusEHR Data & Workflow
Challenge
Modern healthcare applications contain large volumes of structured patient, encounter, condition, practitioner, and status information. Support teams need to understand how these records relate to one another when investigating application or workflow questions.
FHIR resources can also contain nested fields, coded values, and multiple related records, making it important to distinguish raw healthcare data from the information needed for a specific support or reporting task.
Approach
Used Oracle Health's public FHIR R4 environment to retrieve and inspect Patient, Encounter, and Condition resources using REST API requests and structured data queries.
Relevant records were reviewed, filtered, summarized, and converted into readable outputs that demonstrate how technical support or systems staff can trace EHR information across related resources.
EHR Data Workflow
01
Identify the patient resource
Retrieve the appropriate Patient record and confirm basic identifiers and demographic fields before reviewing related data.
02
Review encounter information
Examine encounter status, class, type, location, service provider, and other contextual details associated with the patient.
03
Inspect related clinical records
Query related resources such as Condition records and review clinical and verification status fields.
04
Summarize the results
Filter structured records and convert the relevant values into readable summaries, tables, and visual status reporting.
Core Concepts Explored
FHIR Resources Working with structured Patient, Encounter, and Condition resources returned by an Oracle Health FHIR R4 endpoint.
Encounter Context Reviewing encounter status, class, type, location, service provider, and practitioner involvement.
Status Interpretation Separating clinical status and verification status values when summarizing Condition records.
Nested Healthcare Data Identifying useful values inside nested JSON structures and converting them into readable support and reporting outputs.
Application Support Workflow
01Confirm the Record
Verify that the correct patient or encounter resource is being reviewed before investigating associated records.
02Review Context
Examine status, encounter type, location, provider, and related resource information to understand the workflow context.
03Isolate the Data
Filter large resource sets to identify records relevant to the reported issue, workflow, or reporting question.
04Document Findings
Convert technical FHIR data into a readable summary that can support troubleshooting, documentation, reporting, or escalation.
Project Evidence
Outcome
FHIR RecordsRetrieved Patient, Encounter, and Condition resources
Healthcare DataStructured Nested records converted into readable outputs
Knowledge LevelFoundational Oracle Health and EHR workflow familiarity
Skills Demonstrated
Oracle Health MillenniumFHIR R4REST APIJSONPatient ResourcesEncounter ResourcesCondition ResourcesHealthcare DataData FilteringWorkflow AnalysisApplication SupportTechnical Documentation
Healthcare Systems Portfolio Note
This is an independent portfolio project using Oracle Health's public FHIR R4 environment and test data to demonstrate foundational knowledge of healthcare application workflows, structured EHR data, and transferable application-support skills. It does not represent administration of a production Oracle Health environment or access to real patient information or PHI.
PROJECT 03 / HEALTHCARE SYSTEMS
Oracle Health Data + FHIR
An independent healthcare data integration project exploring how structured FHIR resources can be retrieved, mapped, transformed, validated, and converted into a simplified downstream data format.
Project Overview
SourceOracle Health FHIR R4
FormatNested JSON
TransformationFHIR → Flat Schema
DestinationValidated Record
Challenge
Healthcare data exchanged through FHIR can contain nested JSON structures, coded values, arrays, references, and fields that are not immediately suitable for reporting or downstream systems.
Integration workflows may therefore need to identify required source fields, map those fields to a target schema, preserve valid source values, and verify that required data was successfully transformed.
Approach
Retrieved a Patient resource from Oracle Health's public FHIR R4 environment and worked with the raw JSON response as the source record for the integration workflow.
Selected useful patient fields, documented their source paths, mapped them to a simplified destination schema, generated a flat record, and added validation checks to confirm required fields were present.
FHIR Integration Workflow
01
Retrieve FHIR JSON
Request a Patient resource from Oracle Health's public FHIR R4 endpoint and save the structured JSON response.
02
Identify source fields
Locate required patient values inside the nested FHIR resource, including identifiers, demographics, and language information.
03
Map and transform
Map FHIR JSON paths to simplified destination fields and flatten nested values into a structure another system can consume.
04
Validate the output
Confirm required destination values are present and produce a validated final record for the simulated downstream workflow.
Transformation Concepts
Direct Mapping Source values such as Patient ID and gender can be transferred directly into corresponding destination fields.
Nested Value Extraction Values such as patient name and preferred language are extracted from nested FHIR JSON structures.
Source Preservation Source values such as partial FHIR dates are preserved rather than expanded or altered during transformation.
Destination Validation Required fields are checked after transformation before the destination record is marked as validated.
Integration Data Flow
01Source System
Oracle Health FHIR R4 provides the original Patient resource as structured healthcare JSON.
02Transformation Layer
Nested source fields are selected, renamed, extracted, and converted into a simplified flat schema.
03Validation Layer
Required fields such as Patient ID, BirthDate, and Language are checked before the record is accepted.
04Destination Record
The final transformed record contains clean destination fields and an integration status showing validation success.
Project Evidence
Outcome
Source DataRetrieved Oracle Health FHIR Patient JSON
TransformationMapped Nested JSON converted to flat schema
Validation4 of 4 Passed Required destination checks
Skills Demonstrated
Oracle HealthFHIR R4REST APIJSONFHIR ResourcesData MappingNested DataSchema TransformationData ValidationCSVIntegration WorkflowHealthcare Data
Healthcare Systems Portfolio Note
This is an independent portfolio project using Oracle Health's public FHIR R4 environment and test data to demonstrate foundational knowledge of healthcare data integration, FHIR resources, JSON transformation, field mapping, and validation. It does not represent administration of a production Oracle Health environment or access to real patient information or PHI.