AI Automation Engineer

Monoprice runs a high-SKU direct-to-consumer e-commerce business on a proprietary platform with Microsoft 365 as our productivity backbone. We have AI workspace tools, Copilot, and Claude deployed across the team, with Claude desktop in active use among power users. The gap is not tooling. It is connecting those tools to the data and workflows that would make them genuinely useful for business teams.

This role sits at the center of our AI enablement program. The work is equal parts technical execution and human enablement. You will build data pipelines and automations that make our systems accessible to AI tools. You will train business teams to use what gets built. And you will document what you build so it compounds over time rather than creating a new dependency.

The forward-looking technical work here is extending AI tooling into internal systems via Python connectors and data pipelines. Open-platform automation experience is useful background. As the program matures, the work extends into AI-native tooling: connecting business users to live system data through direct queries and natural language. But the foundation is reliable automation and accessible data first.

This role does not have a defined team under it. You may work alongside product management and change management resources, but you should expect to own the technical execution of the AI enablement program independently and to build the program's reach through training and documentation, not headcount.

What This Looks Like in Practice

A department head tells you their team spends three hours every week pulling data from two systems into a spreadsheet, reformatting it, and distributing it to four people. Before you open any tool, you spend time understanding: what data are they actually pulling, where does it live in our source systems, what format do they need it in, and what happens after distribution.

You come back with a clear picture of what is accessible, what the data pipeline looks like, and what the minimum viable solution is. You build it. You make sure the team can use it without you. You document it so the next person can extend it.

Some of this work is a Power Automate flow pulling from SharePoint. Some of it is connecting our SQL Server source systems to a Postgres destination that an AI tool can query. Some of it is configuring an MCP server so a business user can ask a natural language question against live business data. You size the problem and choose the right approach.

You do not default to the most technically interesting solution.

What You Will Do

Data Access and Pipeline Work

• Build data pipelines that make source system data (SQL Server, M365) accessible to AI tools and business users. The direction is source systems out to accessible destinations:
  Postgres, CSV, or direct AI tool integration.
• Build Python connectors and API integrations that extend AI tooling into internal data sources and systems. MCP server configuration is a growth area as the program scales, not a day-one requirement.
• Understand the data structure of our source systems well enough to scope what is buildable before committing to a solution. SQL Server is the source. It is not interchangeable with downstream destinations.
• Evaluate and use data integration tooling (Airbyte or equivalent) where appropriate. Know when a Python script or direct connector is the simpler answer.

Workflow Automation

• Build and deploy workflow automations using Microsoft Power Automate, Copilot Studio, and open-platform tools where they fit the problem. Prefer the simplest tool that solves the problem reliably.
• Own the full lifecycle: discovery, build, deployment, adoption, documentation. An automation nobody uses or nobody can maintain is not a completed project.
• Maintain a prioritized automation and data pipeline backlog. Communicate progress and blockers to leadership and department heads.

Business Discovery and Requirements

• Conduct workflow and data discovery sessions with non-technical business teams. The job in these sessions is to understand the problem and the underlying data before proposing any solution.
• Scope requirements to the minimum viable solution. Not every use case needs to be automated. Not every edge case needs to be handled in version one.
• Know when to tell a business user that an existing AI tool or automation already solves their problem if connected to the right data. Building something new is not always the answer.

Training and Enablement

• Train business teams on AI tools and automations as they are deployed. Adoption is part of delivery. If the team cannot use it without you, the project is not done.
• Document what gets built: what it connects to, what data it uses, how to maintain it, and how to extend it. The goal is compounding capability, not a new dependency.
• Establish intake processes so business teams can request and prioritize AI enablement work without routing everything through you individually.

Boundaries

• Route to Engineering when work requires changes to our…