Oguzhan Durace

Delivery and adoption

Shadowed sales users, embedded feedback in the workflow and refined the implementation around their work.

The problem

Sales representatives needed account context to prioritise and prepare their next interaction. Repetitive research interrupted the sales workflow.

Implementation or proposed flow

Shadowed sales representatives to identify the research bottleneck, then connected LLM enrichment with Make and Salesforce. Localised the workflow and embedded a feedback widget so users could inform subsequent changes. Owned requirements, acceptance testing and adoption.

The tradeoffs

• Research inside the existing CRM, because representatives could use the result in their normal workflow.
• Iteration with sales users, because local terminology and account context matter as much as the initial model output.

Outcome

40% higher lead conversion at Andercore, with account research integrated into the sales workflow.

What I would watch next

• Enrichment completeness and incorrect account matches
• Conversion by segment and use of enriched records
• Feedback from sales representatives

Delivery and adoption

Started with selected categories and expanded the routing scope through a phased pilot.

The problem

Requests required manual sorting before the responsible team could start resolving them.

Implementation or proposed flow

Connected incoming email, Make and OpenAI to classify requests and route them to the responsible department. Piloted selected categories before expanding. Owned stakeholder alignment, testing, documentation and training.

The tradeoffs

• A limited category pilot, because routing errors are easier to inspect before the scope expands.
• Department ownership in the workflow, because a useful classification must lead to a responsible team and a next action.

Outcome

60% less support triage time at Andercore, following a pilot and expansion into additional routing categories.

What I would watch next

• Incorrect department assignments
• Time waiting for the first responsible owner
• New request types outside the initial categories

Delivery and adoption

Aligned engineering, operations and commercial teams, with field and office users included in the rollout.

The problem

Five departments had different process and data requirements that needed to work together in one operational platform.

Implementation or proposed flow

Owned the product roadmap, user stories and technical specifications. Coordinated migration and a phased rollout of Sales Cloud, Service Cloud and Sitetracker, with approvals, lead routing, onboarding and training for field and office teams.

The tradeoffs

• A phased rollout, because migration dependencies and user readiness needed to be coordinated.
• Shared requirements with explicit priorities, because local process requests still had to fit a coherent data and operating model.

Outcome

Delivered on time and within budget across five departments.

What I would watch next

• Migration exceptions
• Adoption across field and office teams
• Ownership of process changes after rollout

Delivery and adoption

Deployed for personal coordination. Validation, retries, backups and restore behaviour are part of the operating design.

The problem

Natural language requests need to become consistent actions across multiple tools, including when dates are unclear or a downstream service fails.

Implementation or proposed flow

Built and deployed an independent service using OpenAI structured plans and Pydantic validation. PostgreSQL stores plans and operations. Queries cannot carry write actions, ambiguous dates trigger clarification, and retries reconcile earlier writes. Authenticated intake, health checks, backups and a verified restore support operation. I own workflow rules and acceptance, with coding agents supporting implementation.

The tradeoffs

• Deterministic calendar routines, because mirroring and date sorting have explicit rules and need no model call.
• Persisted operations and reconciliation, because a retry must account for an external write that may already have succeeded.

Outcome

Deployed for personal task coordination, with validated actions and tested recovery after failed operations.

What I would watch next

• Duplicate actions after a retry
• Requests that require clarification
• Backup restoration and failed operation recovery

Delivery and adoption

Latest completed editorial milestone: a 22 page pregame format. Next: reader feedback on usefulness and publication quality.

The problem

Raw scores tell readers what happened, but a useful recurring publication needs reliable numbers, context and an editorial structure.

Implementation or proposed flow

Building a publishing workflow that combines official league results and player data with analysis and a designed magazine. Numerical validation comes before editorial generation. Forecasts are fixed before matches and assessed against outcomes. I own scope, data quality, editorial review and preparation for reader launch, using AI coding agents for implementation.

The tradeoffs

• Verified numbers before generated prose, because a persuasive narrative cannot compensate for an incorrect score.
• Forecasts fixed before results, because evaluation is meaningful only when predictions cannot change after the event.

Outcome

The prototype reconciled 60 historical scores and passed 19 regression tests. Current focus: reader testing, editorial usefulness and a repeatable publication workflow.

What I would watch next

• Score agreement with official results
• Editorial usefulness in reader testing
• Publication preparation time

Delivery and adoption

Four focused MCP tools keep source material and working context accessible across AI sessions.

The problem

Research and decisions are easily lost across separate AI conversations, leading to repeated work and inconsistent assumptions.

Implementation or proposed flow

Built a knowledge environment with custom MCP tools for keyword search, full note retrieval, new captures and recent activity. Inputs are validated, article paths are restricted and earlier captures are preserved. Source material stays separate from operating instructions. I use the environment for ongoing research and delivery.

The tradeoffs

• Small tools with explicit file boundaries, because each operation can be understood and checked.
• Keyword search and full source reads, because this implementation needs inspectable retrieval without claiming a vector search platform.

Outcome

Used in ongoing research, planning and project delivery. Fixture checks cover retrieval, capture preservation and file access boundaries.

What I would watch next

• Whether retrieved sources answer the working question
• Stale or conflicting decisions
• Captures that have not yet been reviewed

Delivery and adoption

The prototype separates account enrichment, segmentation and drafting. A person reviews outreach before sending.

The problem

Account research, segmentation and outreach drafting are often separate tasks with inconsistent handoffs.

Implementation or proposed flow

Built a CRM prototype where enrichment, segmentation and drafting agents exchange structured outputs. Segmentation uses deal history and engagement; stage outputs and anomaly flags remain inspectable. I own the business rules, integration choices and acceptance. External outreach remains subject to human approval.

The tradeoffs

• Separate stages, because a failed step can be investigated without rerunning the whole workflow.
• Human approval before outreach, because a draft needs a commercial owner before it reaches another person.

Outcome

Working prototype with reviewable stages. No production customer adoption or conversion result is attributed to this independent project.

What I would watch next

• Incorrect account matches
• Draft quality and required edits
• Errors at handoff between stages

Delivery and adoption

Authored cases make failure patterns inspectable before applying a routing policy to real traffic.

The problem

A routing workflow needs a way to expose incorrect automatic decisions and the requests it sends for review.

Implementation or proposed flow

Built a harness comparing keyword rules with semantic classification on 20 authored support cases. Expected and actual routes and review thresholds remain visible. Failures can be retained as regression cases.

The tradeoffs

• Errors alongside automation coverage, because a higher routing rate is not useful if it hides more incorrect assignments.

Outcome

Working evaluation demonstration. Authored test cases do not establish production accuracy.

What I would watch next

• Wrong automatic decisions
• Review workload
• Coverage of new request categories

The problem

An inquiry may lack dimensions, units, quantity or delivery requirements, leaving the team to collect essentials before preparing a quote.

Implementation or proposed flow

Proposed flow: extract product, dimensions, units, quantity, destination and timing; request missing fields; save the source message and owner in a shared queue; prepare a draft for approval. Related proposals cover approved customer replies, consistent website product information and follow up tracking. Tool choices are proposed, not deployed.

The tradeoffs

• Complete inquiry data before drafting a quote, because fabric units and carpet dimensions cannot be guessed safely.
• Human price and availability approval, because general product information does not establish stock or a delivery commitment.

Outcome

Ready for a scoped pilot with measures for inquiry completeness, preparation time and reviewer corrections.

What I would watch next

• Inquiry completeness
• Quotation preparation time
• Overdue follow ups

The problem

A financial assistant needs to make exceptions visible without producing inconsistent calculations or acting beyond its authority.

Implementation or proposed flow

Design a shared calculation and data layer for scoped finance, accounting and policy assistants. Surface the evidence behind an exception and send consequential actions to a responsible reviewer. The proposal defines pilot criteria for data quality, useful exceptions and reviewer effort.

The tradeoffs

• A shared calculation layer, because financial totals need consistent definitions across assistants.
• Reviewed actions, because an explanation and an instruction to change a financial record carry different consequences.

Outcome

Reference design. A pilot would need to demonstrate correct exception detection and useful reviewer decisions.

What I would watch next

• False alerts
• Evidence completeness
• Time to a reviewed decision

The problem

Invoice handling mixes repeatable extraction with decisions that need purchasing context and accountable approval.

Implementation or proposed flow

Propose structured extraction, deterministic matching against order and receipt data, and an exception queue with source evidence. Partial deliveries and missing references remain visible to a reviewer. Payment execution is outside this proposed workflow.

The tradeoffs

• Deterministic matching, because quantity and value comparisons must follow explicit rules.
• Diagnosed exceptions, because the reviewer needs the mismatch and evidence, rather than only a confidence score.

Outcome

Pilot success would be measured through matching accuracy, reviewer effort and the handling of incomplete documents.

What I would watch next

• Extraction errors
• Incorrect matches
• Reviewer correction time