← All projects

FIELD-BUILT OPERATIONS CASE STUDY / VTO MANAGER

VTO Manager / Portfolio edition

Who leaves early?
A rule, not a race.

VTO (voluntary time off) lets employees leave early when staffing exceeds workload. I initiated a 3+ month, field-led project to replace first-come, first-served allocation with explainable priority, operational safeguards and supervisor confirmation. I designed the business logic and used AI as a development partner, not as the decision maker.

Real shift pilot  ·  Human-defined rules  ·  Public demo uses synthetic records

LGLucas GiulianiMSc ISLI Global Supply Chain Management · KEDGE Business School

AT A GLANCE

Three months of work.
One real operational problem.

An initiative developed alongside daily operations responsibilities, piloted on one shift and later adapted into an independent, synthetic portfolio edition.

AUTHOR-REPORTED3+ months

Analysis, design, iteration and operational project work

FIELD REPORT6+ weeks

Live pilot on a single operational shift

IN THE CODE7 criteria

Ordered individual ranking rules, plus coverage checks

PROJECT HANDOFF50+ pages

Illustrated guide for users and continuity

Reading the evidence: time and field figures are author-reported, not independently audited performance measurements. Code and handover figures describe documented project elements, not measured operational gains.

01 / THE PROBLEM

The old system rewarded
speed, not fairness.

During my operations internship, I was managing a real shift while seeing how a simple allocation process could create tension, interrupt work and leave supervisors without a consistent explanation.

BEFORE / FIRST COME, FIRST SERVED

A race for a place.

Employees left their work area to ask first. Previous departures did not influence priority. Decisions were difficult to explain consistently.

Observed issue: frustration, competing requests and avoidable distraction from the floor.

AFTER / A RULE-BASED APPROACH

A reason behind each recommendation.

Volunteers are ranked on prior departure history, then checked against staffing and qualification requirements. A supervisor confirms the outcome.

Business objective: a fairer process that remains usable and safe for operations.

02 / THE BUILDING JOURNEY

The real challenge was
making it work on the floor.

Building a screen was not enough. The tool had to fit existing management routines, technical boundaries and fragmented information, while I continued my day-to-day operational responsibilities.

THE CONSTRAINT

Improve the process without creating more work.

Supervisors needed a decision they could trust and explain. Operators needed a fair route to request VTO. The solution had to support both, without weakening shift coverage or relying on unrestricted access to internal systems.

3+months of iteration

Hundreds of hours of analysis, discussion, AI-assisted prototyping and adjustments informed by colleagues' feedback, alongside floor-management duties.

  1. 01 / INITIATE

    See the problem. Obtain support.

    I proposed the initiative and received approval from my direct Operations Manager to develop it and, with managers on my shift, to pilot it locally.

  2. 02 / DESIGN

    Translate reality into business rules.

    I analysed human constraints, priority disputes, staffing minima, critical skills and the site-specific constraints of a tightly controlled environment.

  3. 03 / BUILD & ADAPT

    Connect the pieces without moving the data.

    Information was spread across internal sources. I used several AI tools to challenge the approach and especially to help implement the interface, refining it repeatedly with colleague feedback.

  4. 04 / PILOT & HAND OFF

    Prove usability before moving on.

    After initial operator hesitation, the feedback I received by the end of my internship was consistently positive. A stable tool and illustrated documentation were handed over for continuity.

Evidence scope: the sequence, duration and feedback above are the project author's account. Approval to run a shift-level pilot is not the same as organisation-wide deployment or approval of this public portfolio.

03 / THE DECISION ENGINE

Business logic,
made explainable.

The system recommends, it does not decide for a supervisor. Its individual ranking follows explicit, ordered business rules.

INDIVIDUAL PRIORITY

Seven rules. In order.

DETERMINISTIC
  1. 01Fewer departures this week
  2. 02Fewer departures over the last 56 days
  3. 03More waiting / compensation credits
  4. 04Fewer minutes of departure time this week
  5. 05Fewer minutes over the last 56 days
  6. 06Older date of last departure
  7. 07Deterministic tie-break

Additional group-selection logic applies to declared carpools. A high rank never bypasses operational eligibility checks.

▦

Protect the shift

Role minima, critical posts and qualified replacement checks are evaluated before a feasible recommendation.

◈

Respect exceptions

Onboarding restrictions, grouped carpools and eligibility rules add operational context beyond the fairness ranking.

✓

Keep a human accountable

Supervisors review the proposed allocation, record actual departures and provide reasons for exceptional overrides.

Inspect the actual workflow

04 / TRY THE REAL PRODUCT

A working product.
Not just a mockup.

Explore the public portfolio edition with synthetic employees and in-memory changes. The actual decision workflow is ready to test, with no sign-in or setup.

LIVE PRODUCT PREVIEW · SYNTHETIC DATA
01

Prepare

Review the people, volunteers and available places.

02

Calculate

Apply history-based priority and staffing constraints.

03

Review

Inspect the recommendation and any qualified replacements.

04

Confirm

Record actual departures and update the history.

Start with a prepared scenario: 24 scheduled employees, 8 volunteers and 4 places. Changes are temporary; reloading restores the example.

05 / WHAT THE PILOT SHOWED · QUALITATIVE

From initial doubts
to a tool people trusted.

The most meaningful change was not a dashboard metric. It was making departure requests less about who reached a supervisor first and more about a consistent, explainable process.

THE HUMAN SIDE

Early reluctance.
Positive feedback by handoff.

At the start, some operators were reluctant to change a familiar process. I continued adjusting the tool around their feedback and the needs of managers. By the end of the internship, all of the feedback I personally received about the initiative was positive.

VALUE FOR BOTH SIDES

Not just fairer for operators.

Operators no longer had to race to a supervisor to secure priority. Managers gained an explainable order of priority, operational coverage checks and a way to review exceptional decisions. These are process and product capabilities, not quantified productivity gains.

Human-reviewedManager confirms outcomesRule-basedNo AI selects employees
AUTHOR-REPORTED PILOT

The scope, without invented KPIs.

6+ weeks on one shift, approximately 30–40 allocation events managed. The pilot was locally approved and documented; all-site adoption has not been verified.

WHAT WAS NOT MEASURED

Improvement, not a claimed percentage.

Frustration appeared to decrease in day-to-day discussions, but there was no controlled satisfaction survey, audited baseline or statistically measured productivity gain. Positive feedback reflects the comments I received, not every employee's opinion.

06 / BUSINESS INTELLIGENCE · SYNTHETIC DATA

From recording departures
to understanding patterns.

Added after the operational project, the analytics dashboard connects offers, employee interest and actual departures.

SYNTHETIC DATA ONLY

144 employees · 209 events · 56 daysJul 21 – Sep 13, 2026 · Fixed demo snapshot

01 / DEMAND OVER TIME

Offers and interest do not always align.

Weekly trend
Places offeredEligible requestsActual departures
Weekly offers, requests and departures in the synthetic demoA line chart of 8 calendar weeks. Exact values are available in the chart data table. The first and last calendar weeks are partial.075150225300Week of Jul 20: 140 places offeredWeek of Jul 27: 94 places offeredWeek of Aug 3: 183 places offeredWeek of Aug 10: 225 places offeredWeek of Aug 17: 276 places offeredWeek of Aug 24: 178 places offeredWeek of Aug 31: 139 places offeredWeek of Sep 7: 165 places offeredWeek of Jul 20: 140 eligible requestsWeek of Jul 27: 159 eligible requestsWeek of Aug 3: 219 eligible requestsWeek of Aug 10: 181 eligible requestsWeek of Aug 17: 185 eligible requestsWeek of Aug 24: 172 eligible requestsWeek of Aug 31: 167 eligible requestsWeek of Sep 7: 174 eligible requestsWeek of Jul 20: 100 actual departuresWeek of Jul 27: 69 actual departuresWeek of Aug 3: 146 actual departuresWeek of Aug 10: 131 actual departuresWeek of Aug 17: 153 actual departuresWeek of Aug 24: 126 actual departuresWeek of Aug 31: 108 actual departuresWeek of Sep 7: 105 actual departuresJul 20Jul 27Aug 3Aug 10Aug 17Aug 24Aug 31Sep 7Count

Compare the offer, request and departure curves. The first and last calendar weeks contain only part of the 56-day window.

View chart data
Week beginningEventsPlaces offeredEligible requestsActual departures
Jul 2022140140100
Jul 27279415969
Aug 327183219146
Aug 1026225181131
Aug 1727276185153
Aug 2427178172126
Aug 3126139167108
Sep 727165174105
02 / INTEREST BY SHIFT

Compare rates, not headcounts.

AM32.8%
381 requests / 1,160 eligible exposures · 73 events
PM43.9%
536 requests / 1,222 eligible exposures · 74 events
NS47.1%
480 requests / 1,019 eligible exposures · 62 events
0%50%100%

In this synthetic sample, NS has the highest participation rate. Each eligible employee is counted once per offer received.

03 / REQUEST OUTCOMES

Interest is not the final outcome.

67.1 percent of eligible requests resulted in departure938 departures out of 1397 eligible request instances. 459 requests did not result in a departure, across the synthetic dataset.67.1%request fulfillment
938Resulted in departure
459No departure recorded

1,397 request instances, not unique people. Unfulfilled requests include different outcomes; the full dashboard explains them.

Source: the demo’s built-in synthetic event history. These charts describe the sample, not the professional pilot or measured business impact.

07 / AUTHORSHIP & AI TRANSPARENCY

I designed the decisions.
AI helped build the software.

I worked with multiple AI systems over hundreds of hours of exchanges. They challenged my thinking and contributed substantially to the technical interface and implementation. They did not replace operational judgment or receive employee data.

MY ACCOUNTABILITY

Process ownership, not a claim to have hand-coded everything.

The hard work was defining the right problem, formalising decisions that would hold up on a real shift, choosing how to handle exceptions, and iterating until the tool made sense to both operators and supervisors.

HUMAN-DEFINEDBusiness logicAI-ASSISTEDTechnical build
01 / I OWNED

Operational design & decisions

  • Problem analysis and project initiative
  • Priority rules, fairness logic and safeguards
  • Human, technical and site constraints
  • Feedback collection, iteration and local pilot
  • Product handoff and user documentation
02 / AI CONTRIBUTED

Challenge & technical implementation

  • Questioning assumptions and exploring options
  • Challenging proposed rules and edge cases
  • Helping develop interface and application code
  • Supporting debugging and repeated revisions
  • Turning feedback into technical adjustments
03 / AI DID NOT

Access data or make the call

  • Receive real employee records or exports
  • Access operational datasets outside the site
  • Autonomously decide who leaves early
  • Replace supervisor approval
  • Grant organisational or GDPR authorisation
WHY THIS DISTINCTION MATTERS

Two very different uses of AI.

Generative AI assisted development. The working allocation engine itself is deterministic and rules-based: human-specified priorities and safeguards produce a recommendation, and a human supervisor confirms departures. Spreadsheet structures, not their real contents, were shared with AI tools during development.

IMPLEMENTATION / LIMITS

Where did the original operational data live?

According to the author's account, operational information remained within the employer-controlled internal environment, with restricted network access. The initial application used a shared internal data file; the public portfolio edition does not connect to it.

How was the project tested and adopted?

The project was tested on an actual shift over six or more weeks, with feedback used to improve the tool. Documentation refers to automated checks, but the original test suite has not been independently reproduced in this public package. Positive feedback is qualitative and not an independently audited performance statistic.

Does a pilot imply a company-wide rollout?

No. The direct Operations Manager and managers on the shift supported a local pilot. The tool and documentation were handed over, but verified daily adoption across other shifts has not been established.

Is this public demo the original production system?

No. It is an independent, adapted portfolio edition using synthetic fixtures and an in-browser example. It does not use the internal shared data source. The later analytics section is also a portfolio extension.

08 / PRIVACY, SECURITY & GDPR

Real data stayed internal.
The public demo is synthetic.

Privacy is not a slogan. There are three different data contexts here, and the claims we can make about each are deliberately separated.

01PROFESSIONAL PILOT / AUTHOR ACCOUNT

Employer-controlled environment

Real operational information stayed in the employer's internal systems and restricted shared environment. I did not send employee records or operational datasets to external AI services; AI tools were shown spreadsheet structures only.

A manager-authorised shift pilot does not establish a formal data-protection assessment or permission to publish employer materials.

02PUBLIC EDITION / CODE CHECKED

Fictional records, local interactions

The downloadable site bundle contains synthetic employee records and event histories, with no connection to the original employer data. Allocation calculations and example edits run in the browser. No app-level endpoint sending VTO records was found in the inspected files.

Some layout preferences may persist in your browser. Visitors should not import real people or confidential data into a public demonstration.

03WEBSITE DELIVERY / TO VERIFY

Hosting is not zero processing

Cloudflare necessarily receives web requests and may process IP addresses, security signals and other connection metadata. Hosting logs, network cookies, retention and geographic processing depend on the deployed Cloudflare configuration.

Those account-level settings have not been audited. This site does not claim a GDPR certification or blanket compliance.

A PROJECT YOU CAN ACTUALLY EXPLORE

Three months of problem-solving.
One working decision tool.

Designed, piloted and documented by Lucas Giuliani
MSc ISLI Global Supply Chain Management · KEDGE Business School