01
Build Operations
Design workflows, controls, documentation, responsibilities and teams from the ground up.
Operations · Logistics · Technical Operations · Miami, FL
I solve operational problems where technology, logistics and people meet.
I build and improve the systems behind device operations, inventory, deployments, technical support, vendors and cross-functional execution.
My work usually starts with a messy operational problem and ends with a process that can be executed, measured and repeated.
20+ yearsworking across technical and operational environments
115,911Android POS terminals prepared and quality-controlled
End-to-endreceiving, configuration, QA, inventory, dispatch and support
LATAM + U.S.cross-border operations, suppliers and technical coordination
What I actually do
Not one job title. One operational pattern.
My roles have crossed operations, logistics, technical support, QA and product work. The common thread is turning complex requirements into working processes.
02
Run Logistics
Coordinate receiving, inventory, purchasing, vendors, configuration, warehousing and dispatch.
03
Solve Technical Problems
Investigate incidents, reproduce failures, coordinate OEMs and developers, validate fixes and deploy corrections.
04
Turn Products Into Operations
Translate technical products into workflows that real teams can deploy, support and operate consistently.
Selected work
Evidence through real operational problems.
Use the filters to view the same experience from different hiring angles. This is intentionally broader than a traditional resume.
Case 01 · Large-scale device operations
Building and scaling the operations supporting 115,911 Android POS terminals
Designed and coordinated a controlled operating flow for serialized payment devices, combining logistics, hardware QA, configuration, preparation, shipping, technical support and PCI-related security controls.
Receiving→Inventory→Hardware QA→Configuration→Dispatch→Support
Case 02 · Cost & fleet intelligence
Building a monthly cost-intelligence dashboard for a large device fleet
Consolidated fragmented data from multiple operational platforms into a single view that explains what is being charged, why the cost exists, which network incurred it and what operational action can reduce it.
Multiple sources→Serial reconciliation→Cost attribution→Root cause→Action
Case 03 · Deployment recovery
Recovering a blocked Fortix device-management pilot
Coordinated incident analysis, operational workaround, requirements redesign, QA and production validation after APN and connectivity restrictions blocked a pilot of approximately 100 devices.
Failure→Root cause→Workaround→Redesign→QA→Acceptance
Case 04 · Hardware quality
Turning recurring display failures into supplier corrective action
Consolidated field evidence, isolated the affected hardware pattern, escalated the issue to the OEM and coordinated replacement units and spare LCD recovery.
Field reports→Evidence→OEM escalation→Corrective action→Recovery
Case 05 · Inventory redesign · In progress
Designing a traceable operating system to replace spreadsheet-and-email inventory control
Designed a low-volume but control-sensitive inventory process around validated movements, stock integrity, auditability, location control and management visibility; implementation is in progress.
Manual process→Requirements→Controls→Validated workflow→Reporting
Developed case study
Large-Scale Android POS Operations
A public, anonymized example of how I turn a high-volume technical operation into a controlled and repeatable process.
Flexipos Corp. · Payment technology operations
Building the operations supporting a growing Android POS fleet
Each serialized payment terminal had to pass through a controlled lifecycle combining logistics, hardware quality validation, software preparation, configuration, device preparation, technical support and security controls appropriate to the online device-signing and application-installation workflow.
115,911Android POS terminals prepared and quality-controlled
Growing fleetThe environment continues to expand
Serialized assetsTraceability required throughout the lifecycle
The operational challenge
High device volumes create multiple failure points: receiving errors, incorrect inventory assignment, hardware defects, wrong software configuration, loss of traceability or technical incidents after deployment. The operation needed to work as a system, not as a collection of individual tasks.
My role
I designed, coordinated and improved much of the operational process behind these deployments, working across logistics, technical support, QA, suppliers and internal teams.
Responsibilities
- Receiving, preparation and dispatch workflow design
- Serialized inventory control
- Hardware QA before software configuration
- Software preparation and device configuration
- Recruiting and operational team training
- Transportation and dispatch coordination
- Parts, accessories and replacement equipment management
- Purchasing and supplier coordination
- Second- and third-level technical support
- OEM, QA and developer escalation
- Controls for the online device-signing and application-installation workflow
PCI scope
The physical handling and preparation process itself was not subject to PCI requirements. controls for online signing and application installation applied to the online device-signing and application-installation workflow through the device-management platform.
What made the work transferable
I had to understand what the technology required, translate it into a workflow, prepare the people and resources needed to execute it, and then verify that the process worked in production.
Illustrative operational control map
Public visual summary of the real operating logic: how serialized terminals move through the process and where the main control points exist.
1
Receiving
Identify inbound units, quantities and source, and preserve traceability from the first handoff.
2
Inventory
Register serialized equipment, location and status before any technical intervention.
3
Hardware QA
Validate physical condition and module functionality before software work begins.
4
Configuration
Install applications, apply signing/configuration steps and prepare each unit consistently.
5
Preparation
Final review, packaging and readiness checks before release to logistics.
6
Shipping
Dispatch equipment with documentation, route control and accountability to destination.
7
Support
Manage incidents, escalations and lifecycle events once devices are in the field.
8
Lifecycle control
Maintain status, traceability and operational control throughout the fleet’s ongoing use.
Core control objectives
✓
Serialized traceability across each stage of the process
✓
Hardware validation before configuration to reduce downstream rework
✓
Consistent preparation workflow for temporary staff and scalable operations
✓
Controlled handoff from technical preparation to dispatch and field support
Risk and compliance checkpoints
•
Wrong-unit or wrong-status inventory assignment
•
Hardware defects reaching configuration or field deployment
•
Incorrect application or device signing workflow
•
Weak controls around online device signing or application installation
The real operation includes more detailed controls; this public view highlights the structure behind the process.
What this case demonstrates
The underlying capability is not simply managing POS terminals. It is building and operating a system capable of moving large volumes of serialized technology from supplier to production while maintaining control, traceability, security and technical quality.
Developed case study
Cost Intelligence & Fleet Operations Dashboard
A public, anonymized example of an ongoing monthly process that turns fragmented device-management and operational data into explainable cost, fleet and action-oriented management information.
Flexipos Corp. · Cost and fleet management
Making platform costs understandable, attributable and actionable
Before this initiative, cost information was distributed across separate platforms, exports and operational records. It was possible to see that a charge existed, but not easily explain what generated it, which network or operating group was responsible, whether the cost was expected, or what could be changed to reduce it.
large serialized fleetFleet-scale operating context
Multiple platformsDevice-management, operational and historical data reconciled together
Monthly cycleMeasure, explain, act and verify
The operational problem
Platform invoices showed the financial result, but not the operational cause behind it. The information required to explain each cost lived in different places: active device inventories, management-platform records, application activity, fleet ownership, support actions and historical changes.
My role
I designed and evolved the analytical logic used to reconcile those sources, classify devices and activities, attribute costs to their operational cause, and convert the result into a monthly management process rather than a one-time report.
What the dashboard had to explain
- How many devices were generating cost in each platform
- Which commercial network or operating group was responsible for that cost
- Why each device was active or being managed
- Whether the cost came from new deployment, reactivation, recreation, application management, support or another operational cause
- Which devices appeared in one platform but not another
- Where duplicate, missing or inconsistent classifications existed
- What actions could reduce unnecessary recurring cost without breaking operational support
Reconciliation before visualization
The key step was not the dashboard itself. It was reconciling unique serial numbers across sources and assigning one defensible operational cause to each device. Differences between platform populations were surfaced explicitly instead of being hidden inside aggregate totals.
From cost to root cause
Instead of presenting only totals, the model connected financial cost to operational behavior. A monthly increase could be explained by events such as new equipment entering service, a large software deployment, device recreation or reactivation, application-management activity, or support-driven actions.
From analysis to action
The dashboard became part of a recurring cost-management cycle: measure the active fleet, identify the devices and activities generating charges, explain the cause, decide which inventory or platform adjustments were safe, implement them and then verify the impact in the following cycle.
Illustrative dashboard snapshot
Public mockup based on the real management logic: anonymized, simplified and not built from live company data.
Sample data
9,842
Billed devices this cycle
4 networks
Fleet segmented by commercial network / operating group
1,126
Devices requiring explanation or follow-up action
3 actions
Safe cost-reduction actions identified for the next cycle
Cost by operational cause
Example view: the real dashboard explains the financial total by linking each billed device to one operational cause.
Follow-up action view
| Issue | Interpretation | Action |
|---|---|---|
| Population mismatch | Devices billed in platform A but not visible in control source | Reconcile serials and validate status |
| Unexpected cost spike | Increase linked to reactivations during field support | Review support policy and verify necessity |
| Network concentration | One network carrying a disproportionate share of new cost | Audit onboarding and fleet cleanup actions |
What this case demonstrates
The transferable capability is building management visibility where none existed before: combining fragmented operational data, reconciling it at asset level, connecting cost to cause, and turning the result into a repeatable decision process that improves both financial control and fleet operations.
Developed case study
Fortix Deployment Recovery
A public, anonymized example of how I handled a blocked technical deployment from field failure through operational recovery, redesign, QA and client acceptance.
Flexipos Corp. · Fortix device management
Recovering a blocked pilot of approximately 100 Android POS devices
Fortix was being introduced to manage Android POS devices operating with a private mobile-network configuration. During the pilot, restrictive device policies blocked the APN configuration required for connectivity, preventing devices from completing the expected registration and operational setup.
~100 devicesPilot scope
Private APNConnectivity depended on controlled mobile-network settings
Client acceptanceProduction validation completed successfully
The operational challenge
The problem was not simply a software defect. It created an operational deadlock: Fortix needed network connectivity to manage the device, but the device required access to network settings before that connectivity could be established.
My role
I coordinated the operational and technical response between the client, internal support and QA teams, and the Fortix development team, keeping the pilot moving while the permanent correction was designed.
Recovery and redesign
- Reproduced and documented the field behavior
- Separated the APN/connectivity issue from unrelated device or application problems
- Identified the conflict between Fortix policies and initial network setup
- Coordinated a controlled temporary support policy so devices could be configured and returned to service
- Translated field findings into specific functional and operational requirements
- Included scenarios for initial setup, APN configuration, offline conditions, devices without SIM and controlled Quick Settings access
QA and closure
Once the redesigned Fortix version was available, I defined and executed field-oriented QA scenarios on production-equivalent devices. Validation covered the complete operating sequence, not only isolated functions. The updated version passed production testing, and the client formally accepted the installation and APN configuration results.
Recovery flow
Pilot→
Connectivity Failure→
Root Cause→
Operational Workaround→
Requirements Redesign→
QA→
Production Validation→
Client Acceptance
What this case demonstrates
The transferable capability is managing a technical problem from field failure through operational continuity, requirements definition, QA and final closure — without treating development completion as the end of the problem.
Developed case study
Hardware Quality & Supplier Recovery
A public example of how recurring field failures were converted into structured evidence, OEM escalation and a concrete replacement and spare-parts recovery plan.
Flexipos Corp. · Android POS hardware quality
Turning recurring display failures into supplier corrective action
A recurring LCD failure pattern began appearing in a deployed Android payment terminal model. The operational risk was larger than the individual failures: if the pattern continued unchecked, it could increase service workload, replacement demand and downtime across the installed base.
500 unitsReplacement equipment secured from the supplier
600 LCDsSpare display assemblies secured for repair capacity
OEM escalationField evidence converted into supplier action
The operational challenge
Individual failures can be treated as isolated repair events. The real challenge was determining whether the incidents represented a broader quality pattern, documenting enough evidence to support escalation and reducing the impact on field operations while the supplier response was being defined.
My role
I coordinated the technical and operational investigation, consolidated failure information, worked with the OEM supplier, and translated the issue into a recovery plan involving both replacement equipment and repair parts.
From failures to evidence
- Collected and consolidated recurring LCD failure reports
- Compared affected devices to identify a common hardware pattern
- Separated the issue from software or configuration causes
- Structured the technical evidence required for OEM escalation
- Tracked the impact on service and replacement operations
Supplier recovery
The escalation resulted in a concrete recovery package: 500 replacement terminals and 600 LCD assemblies to increase repair capacity. This addressed both immediate equipment replacement needs and the longer-term ability to recover failed terminals locally.
Corrective-action flow
Field Failures→
Evidence Collection→
Pattern Identification→
OEM Escalation→
Replacement Plan→
Spare Parts Recovery
What this case demonstrates
The transferable capability is recognizing when repeated service incidents are actually a supplier-quality problem, building the evidence required to escalate it, and converting the escalation into an operational recovery plan rather than treating failures one device at a time.
Developed case study
Inventory Process Redesign
A public, anonymized example of how I redesigned a manual inventory process around traceability, validation and operational control.
Flexipos Corp. · Inventory operations · In progress
Designing a traceable workflow to replace spreadsheet-and-email inventory control
The existing process depended on spreadsheets, email exchanges and manual knowledge. Transaction volume was relatively low, but the operation handled serialized technical equipment across more than one physical location, making data quality and traceability more important than transaction speed.
2 locationsInventory control across separate operating sites
Validated movesEach stock movement checked against business rules
Audit trailWho, what, when, where and why captured for each movement
Project status
In progress. The operating model, classifications, validation rules and control requirements have been defined. Implementation, baseline certification and reporting rollout are being completed in stages.
The operational challenge
The weakness was not high transaction volume. It was control. Manual updates made it difficult to guarantee that stock existed before a movement, prevent duplicate entries, distinguish equipment condition, track transfers between locations or reconstruct how the inventory reached its current state.
My role
I redesigned the process from the operating rules outward: defining what a valid movement was, which controls were mandatory, how exceptions should be handled, what information needed to be retained and what management needed to see.
Control framework
- Defined stock status classifications such as new, used, damaged and pending review
- Required valid item identification and positive movement quantities
- Prevented transfers where origin and destination were the same
- Blocked outbound movements that exceeded available stock
- Captured movement ID, date, user, origin and destination for traceability
- Added duplicate-prevention logic and confirmation before final submission
- Linked inventory adjustments to an explicit reason and supporting record
Operational visibility
The design includes stock-level alerts, unit-cost visibility, transfer notifications between locations and management reporting. The implementation is being staged around those controls rather than treating the existing inventory file as the system of record.
Clean starting point
Before migrating the existing inventory, I identified a separate risk: carrying old inconsistencies into a new system. The planned starting point is a certified physical inventory using the new classifications, creating a cleaner operational baseline instead of automating uncertain historical data.
Why this matters
A simple system can still require strong control design. The project focused on preventing bad data at the point of entry, preserving accountability and making inventory status understandable without depending on one person's memory.
Redesign flow
Manual Process→
Risk Identification→
Business Rules→
Validation Controls→
Traceable Movements→
Alerts & Reporting→
Certified Baseline
What this case demonstrates
The transferable capability is designing operational control before selecting or automating the tool: defining the rules that protect stock integrity, making exceptions traceable and creating a process that can be audited and handed off to someone else.
AI + Operations
AI is useful when it improves the work, not when it decorates it.
I use AI as an operational tool: to structure data, accelerate investigation, draft requirements, validate information and turn fragmented inputs into usable outputs.
Operational data
Reconcile cost, fleet, shipment, inventory and device information before turning it into decision-ready reporting.
Raw data → validation → analysis → dashboard
Technical investigation
Use structured prompts and evidence to separate symptoms from causes, define test cases and improve communication with technical teams.
Incident → evidence → hypothesis → test → corrective action
Process design
Translate operating needs into requirements, workflows, validations, documentation and lightweight automation.
Need → requirements → workflow → automation → SOP
Career map
One career, expanding operational scope.
The titles changed less than the responsibility. Over time, technical support expanded into service operations, logistics, infrastructure, inventory, product operations and large-scale device operations.
2005–2021
Sitio Uno C.A. / Flexipos
Executive Assistant to GM → Operations Manager
- Supported company growth from approximately 7 to 70 employees
- Built and managed a technical service center from the ground up
- Directed operations handling up to 1,500 repairs per month
- Managed approximately 3,000 terminals and 50,000 spare parts/components
- Directly managed a team of approximately 25 employees
- Led logistics, inventory, procurement, transportation, facilities and vendor coordination
→
2022–Present
Flexipos Corp.
Technical Operations Coordinator
- Preparation and quality control of 115,911 Android POS terminals
- Serialized-device lifecycle, inventory and logistics coordination
- Level 2/3 technical support and QA
- OEM, supplier and developer coordination
- Cost and fleet intelligence reporting
- Process improvement, operational requirements and AI-assisted analysis
Capabilities
Skills grouped by how the work gets done.
Operations
- Process design
- SOPs
- Workflow improvement
- Operational controls
- Team coordination
Logistics
- Inventory
- Shipping & receiving
- Purchasing
- Vendor management
- Spare parts
Technical
- Android devices
- Hardware QA
- Troubleshooting
- Technical support
- Deployments
Product Ops
- Requirements
- Acceptance testing
- Rollouts
- Backlog coordination
- Cross-functional execution
Data & AI
- Data structuring
- Information validation
- Operational analysis
- Workflow automation
- Management reporting
Resume & contact
Need the traditional version?
This portfolio explains how I work. My operations resume provides the formal employment history.