Lean Six Sigma for Hotel Apartment Operations AI Toolkit

Who this helps: Hotel Apartment improvement leads, quality managers and Lean Six Sigma practitioners.
What you can do: Use the prompts to structure DMAIC, VOC, Pareto, cause analysis and control plans using evidence for human review.

#Lean Six Sigma prompt toolkit

Track C · Hotel Apartment & Serviced Apartment AI Operations Playbook · Lean Six Sigma chapter

Hotel Apartments generate operational variation every day: arrival peaks, late departures, room-readiness delays, repeat defects, complaint categories, housekeeping rework, maintenance revisits, utility spikes, inventory shortages, long-stay exceptions and service-recovery cases.

That does not mean every variation deserves a Six Sigma project.

Lean Six Sigma becomes useful when management can define a real process problem, measure it consistently, understand what matters to the guest or business, test causes rather than guess them, improve the process and hold the gain.

The operating principle for this chapter is:

AI may accelerate structured problem-solving. It must not manufacture data, convert correlation into causation, invent statistical significance, create financial savings, or replace the process owner’s judgment.

The ten prompts follow one improvement cycle:

Charter → VOC/CTQ → Measure → Prioritize → Hypothesize → Analyze risk → Quantify waste → Test capability → Control → Prioritize the next improvement

This chapter continues the fictional 60-unit UAE serviced-apartment case used throughout the playbook. All property figures, costs and performance examples are illustrative unless specifically linked to a verified external source.

#Lean Six Sigma in hotel apartments: improve the process, not the PowerPoint

Hospitality teams often know Lean Six Sigma through tool names: DMAIC, Pareto, fishbone, FMEA, control charts, capability, 5S and kaizen. The risk is turning those tools into presentation exercises.

A hotel apartment improvement project should begin with an operational question:

What is failing or varying?
Who experiences the impact?
What process creates the outcome?
How do we define a defect?
What is the denominator?
Is the measurement trustworthy?
What causes are plausible?
Which causes can we actually test?
What change can be piloted?
How will we know the improvement held?

ASQ describes DMAIC as a structured method for improving existing processes that do not meet performance standards or customer expectations, with Define, Measure, Analyze, Improve and Control building on one another. Its Measure phase emphasizes understanding the real process, validating measurement and establishing a trustworthy baseline. In hotel apartments this matters because operational data are often split across PMS, CMMS, CRM, housekeeping records and manual handovers.

The most useful role for AI is therefore not “be my Black Belt and tell me the answer.” It is to structure the problem, challenge definitions, expose missing data, organize observations, calculate transparently, generate testable hypotheses, compare evidence and document the control plan.

#The Lean Six Sigma HOTEL model

H — Hospitality role & human owner

Who sponsors the project? Who owns the process? Who provides subject-matter expertise? Who reviews statistics? Who validates financial benefits?

O — Operational objective & context

Which process, department, property, guest journey, period and population are being studied? Is this a DMAIC project, kaizen event, routine quality review or new-process design problem?

T — Trusted inputs & sources of truth

Which PMS, CMMS, Finance, CRM, housekeeping, survey or approved operational records define the baseline? Are definitions stable? Are timestamps, units, exclusions and denominators known?

E — Expected output, exceptions & evidence

What decision must the analysis support? What formula or method is being used? Which assumptions and data-quality issues must remain visible?

L — Limits, privacy & leadership approval

What may AI not conclude or authorize? Which analyses require qualified statistical, financial, engineering, HR, safety or legal review?

The improvement system should never allow a language model to convert a neat table into authority.

#Fictional UAE case: room readiness as a DMAIC project

Illustrative scenario

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation

Continue with the fictional 60-unit serviced-apartment operation.

Evidence

Management believes room-readiness delays are creating guest dissatisfaction, coordination work and occasional compensation. The weak project statement would be:

“Housekeeping is too slow. Improve room readiness.”

That statement is not ready for DMAIC. It assumes a cause, blames one department and provides no measurable definition.

A stronger draft statement would say that, during a defined study period, a measured proportion of relevant arrivals was not released by an approved readiness threshold, with the baseline and denominator to be confirmed from PMS, housekeeping and engineering records before the charter is approved.

The team may later discover several contributors: late departures, cleaning workload, inspection queues, engineering blockers, linen constraints, room moves, access issues, inaccurate ETA assumptions, weak handover or inconsistent status updates.

The point of DMAIC is to discover which factors actually matter.

Check the apartment status, inspection results, open defects, required amenities and the approved release criteria.

Decision

Decide whether the apartment meets the release standard or must remain on hold with an accountable defect owner.

Action

Allocate the correction, coordinate housekeeping and engineering dependencies and update the readiness record.

Verification

Reinspect failed items and confirm the authorised release; a completed task alone does not prove the apartment is ready.

#Define: the charter prevents the project from becoming everything

Prompt 121 builds the DMAIC charter.

A professional charter should contain the problem statement, customer impact, measurable baseline field, target field, in/out-of-scope boundaries, start/end points, sponsor, process owner, improvement lead, stakeholders, timeline, constraints, initial risks, benefit hypothesis and data gaps.

“Reduce operational problems across the hotel apartment” is not a project.

“Reduce repeat work orders for a defined asset family” may be.

Scope protects the team from endless analysis.

#Voice of the Customer is not the same as a list of comments

Prompt 122 converts verified VOC into CTQs.

Hospitality organizations collect guest voice through surveys, reviews, complaint logs, call/chat records, corporate-client feedback, long-stay reviews, mystery guest programs and account meetings.

The danger is treating a set of comments as representative when it may be self-selected.

If several guests say “communication was slow” during maintenance cases, that observation can support a theme. It does not prove all maintenance cases have the problem.

A CTQ might become: percentage of guest-impacting work orders where a verified status update is sent within the approved interval.

Now the team needs a start event, timestamp, interval, denominator, exclusions, source system and process owner.

#Defect definitions determine whether the data mean anything

Before a Pareto, capability calculation or trend chart is useful, the team needs a stable defect definition.

“Room readiness failure” could mean not released by 14:00, not released by confirmed arrival, not released by contractual check-in, released with a blocking defect, a guest wait due to status mismatch, or a room reclean after inspection failure.

These are not interchangeable.

Definition drift also affects complaint categories, repeat maintenance, first-time fix, reclean, no-show, SLA breach, compensation and utility anomalies.

AI should challenge definition drift before comparing periods.

#Measure: denominators matter more than impressive percentages

A hotel apartment may report “20 room-readiness complaints this month.” That number is incomplete.

Twenty out of how many relevant arrivals?

Useful denominators include per 100 arrivals, occupied room nights, work orders, departures, housekeeping services, audited opportunities or another exposure measure matched to the process.

AI can calculate rates. The process owner must approve the operational definition.

#Pareto analysis: focus, not mythology

Prompt 123 supports Pareto analysis.

A Pareto chart is useful because it compares categories rather than letting the most recent issue dominate attention. But the 80/20 idea should not become a target that the data are forced to fit.

The analyst should also ask whether frequency is the right measure. A low-frequency life-safety defect cannot be deprioritized because it sits low on a frequency Pareto. Cost, downtime, severity or risk views may be needed alongside frequency.

#Analyze: hypotheses are not root causes

Prompt 124 builds a root-cause hypothesis register.

A root cause should survive a test.

For a room-readiness delay, possible hypotheses might include same-day turnover volume, late departures, engineering visibility, inspection capacity, linen timing, unreliable ETA data or workload allocation.

Each hypothesis should include evidence for, evidence against, required data, proposed test, confounders and subject-matter owner.

AI is excellent at generating possibilities. It is not evidence that those possibilities are true.

#Fishbone: organize causes without creating groupthink

Prompt 125 facilitates a fishbone session.

Cause families can include People, Process, Technology/System, Materials/Inventory, Equipment, Environment, Measurement and Management/Policy. The categories should fit the process instead of copying a manufacturing template mechanically.

The facilitator should preserve minority views, contradictions, unknown branches and questions needing evidence.

The fishbone is a hypothesis map, not a voting contest.

#FMEA: prioritize failure risk without outsourcing judgment

Prompt 126 drafts a process FMEA.

Hotel Apartments contain many handoff failures: reservation notes not reaching Front Office, fixed engineering defects not reflected in room status, cleaned rooms not inspected, guest requests without owners, compensation promises above authority or transport changes not reaching hotel apartment arrival planning.

A draft FMEA can organize Process step → Failure mode → Effect → Cause → Prevention control → Detection control → Owner.

If the property uses Severity, Occurrence and Detection scores, AI should not invent them. A safety-sensitive failure may require specialist review regardless of RPN.

AI can ask better questions. It cannot accept risk.

#Cost of Poor Quality: quantify waste without inventing savings

Prompt 127 structures COPQ.

Hotel Apartment COPQ may include reclean labor, repeated engineering visits, outsourced emergency repairs, room downtime, guest compensation, refunds, replacement items, express laundry, wasted amenities, duplicated administrative handling, overtime and avoidable recovery cost.

The model should distinguish hard savings, cost avoidance, capacity benefit and revenue impact.

AI should never present all four as “cash saved.”

#Illustrative COPQ calculation

Use an illustrative example only.

Assume the fictional property records 18 repeat housekeeping recleans at AED 45 incremental handling cost, 7 repeat engineering visits at AED 85 incremental cost, and 3 service-recovery credits averaging AED 120.

Recleans: 18 × 45 = AED 810

Repeat visits: 7 × 85 = AED 595

Recovery credits: 3 × 120 = AED 360

Illustrative monthly COPQ = AED 1,765

This is not a benchmark or real-property claim. Finance should validate costs, exclusions and potential overlap.

#Capability: a mean is not a capable process

Prompt 128 is intentionally conservative.

Before capability analysis, ask whether the CTQ is appropriate, specification limits are real requirements, the process is sufficiently stable, the measurement system is adequate, process segmentation is understood, assumptions are suitable and sample size is adequate.

A management target is not automatically a specification limit. A control limit is not a specification limit.

AI can prepare a capability review plan. Statistical interpretation should be reviewed by someone competent in the method.

#Control charts: do not confuse common and special causes

A process can move up and down every day without being “out of control.” Conversely, an average may look stable while a special-cause signal is emerging.

A hotel apartment might monitor room-ready time, check-in duration, work-order response time, reclean rate, complaint update interval, linen loss or occupancy-normalized utility consumption.

The chart type depends on the data. The purpose is to distinguish signal from routine variation, not to create decorative analytics.

#Improve: pilot before scaling

Before full rollout, define the pilot area, owner, start/end dates, expected mechanism, measures, balancing measures, risks, training, rollback condition, guest-protection rule and evidence required.

Improvement is experimentation with controls.

#Control: hold the gain or the project is not finished

Prompt 129 creates the control plan.

A useful control plan connects the CTQ, metric definition, source, owner, review frequency, approved threshold, reaction plan, evidence record, SOP and audit linkage.

Control planning prevents the improvement from living only in a project file.

#Kaizen: prioritize manageable improvements without ignoring risk

Prompt 130 prioritizes a backlog.

A prioritization matrix may consider guest impact, defect reduction, effort, implementation time, dependency complexity, reversibility, data confidence, staff burden, financial impact and strategic alignment.

Risk is a gate, not just another weighted score. Privacy, safety and regulatory issues must not be pushed down because they have low ROI.

#Lean waste in hotel apartment operations

Hotel Apartment examples include waiting for verified status, excess employee motion to locate supplies, unnecessary transportation of items, duplicate data entry, excess or expiring inventory, recleans and repeat repairs, unused reports and frontline expertise that is never incorporated into process design.

Some apparently “extra” work is necessary control work. Validate before removing it.

#AI failure modes in Lean Six Sigma

Common AI failure modes include false precision, definition drift, cause inflation, statistical-method mismatch, benefit inflation, confirmation bias and data leakage.

The control is simple: make the method, data, assumptions and human reviewer visible.

#KPI dashboard for an improvement program

Useful governance KPIs include active DMAIC projects, projects with validated baseline, projects with approved CTQ, validated root causes, pilot success rate, sustained-control rate, Finance-verified benefits, COPQ reduction, overdue control actions and data-quality defects.

A dashboard should not reward project volume.

#30-day implementation plan

Days 1–5 — Select and define: choose one process problem, identify sponsor/process owner, draft the charter, define boundaries and list data gaps.

Days 6–10 — Measure: validate defect/denominator definitions, map the current process, verify extraction, capture VOC/CTQs and build the first Pareto.

Days 11–15 — Analyze: stratify the data, run cause workshops, draft an FMEA and identify tests that can confirm or reject hypotheses.

Days 16–20 — Quantify and design: structure COPQ, review capability prerequisites, select a pilot and define balancing measures.

Days 21–25 — Pilot: implement the approved pilot, capture before/after data, observe unintended effects and keep exceptions visible.

Days 26–30 — Control: build the control plan, transfer approved changes into SOP/training, prioritize the next kaizen backlog and validate benefits where applicable.

#Management checklist

Before accepting an AI-supported Lean Six Sigma output, verify the problem is measurable, process boundaries are clear, defect definition is stable, denominator matches exposure, data sources are traceable, VOC limitations are visible, CTQs have definitions, calculations show assumptions, Pareto categories are consistent, root causes are tested, FMEA scoring follows the approved scale, capability prerequisites are met, COPQ avoids double counting, Finance validates financial benefits, pilots have balancing measures, control plans have owners, sensitive data are minimized and final decisions remain human.

#Connected knowledge across Ahmed Quality Ops

Use this chapter with Hotel Apartment Quality Audit AI Toolkit, Hotel Apartment SOP & Process Design AI Toolkit, Hotel Apartment Complaint & Service Recovery AI Toolkit, Housekeeping Management AI Toolkit, Engineering & Maintenance AI Toolkit, Predictive Maintenance AI Toolkit, Hotel Apartment KPI & Dashboard AI Toolkit, SOP Exception & Escalation Management, SOP Roles/Authority/RACI and the Tourism Quality & SOP AI Toolkit.

The knowledge flow should be:

Audit detects → DMAIC learns → process changes → SOP controls → KPI monitors → audit verifies

#Sources and evidence boundaries

External methodology context is grounded in ASQ’s DMAIC and Six Sigma resources. The 60-unit UAE scenario, costs, defect counts and calculations in this chapter are illustrative operating examples and do not represent a specific hotel's actual performance.

#The 10 copy-ready prompts

The prompt library below uses the HOTEL framework and explicit Lean Six Sigma guardrails.

Copy-ready working library

Ten professional prompt templates

Copy, adapt and verify each template before operational use.

Prompt 01

#DMAIC Project Charter Builder

Define a hotel apartment improvement project before analysis begins, with a measurable problem, scope, customer impact, baseline, goal, team and decision rights.

When to use it

Define a hotel apartment improvement project before analysis begins, with a measurable problem, scope, customer impact, baseline, goal, team and decision rights.

Required inputs

verified problem statement
process scope and boundaries
baseline metric and denominator
VOC/guest or stakeholder impact
business impact
project sponsor and process owner
known constraints and timeline

Illustrative scenarioWorked example: DMAIC Project Charter Builder

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: A 60-unit serviced-apartment operation wants to reduce room-readiness delays without turning the project into a general 'fix housekeeping' initiative.
Evidence: Check the supplied verified problem statement, process scope and boundaries, baseline metric and denominator, VOC/guest or stakeholder impact, business impact. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the dmaic project charter builder draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

ROLE
Act as a senior Lean Six Sigma and hotel apartment operations improvement analyst supporting an accountable human process owner. Your role is structured problem-solving, data challenge and improvement support—not autonomous operational, statistical, financial or safety authority.

H — HOSPITALITY ROLE & HUMAN OWNER
Supported role: [Process Improvement Lead / Quality Manager / Department Head / Black Belt / Green Belt / Other]
Accountable process owner/sponsor: [Insert authorized role]
Qualified statistical/technical reviewer when required: [Insert role]

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Define a hotel apartment improvement project before analysis begins, with a measurable problem, scope, customer impact, baseline, goal, team and decision rights.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- verified problem statement
- process scope and boundaries
- baseline metric and denominator
- VOC/guest or stakeholder impact
- business impact
- project sponsor and process owner
- known constraints and timeline

For every dataset or source record, state the system/document, extraction or revision date, owner, unit of analysis and relevant denominator.
If definitions changed between periods, expose the change before comparing results.
If an essential input is missing, stale, contradictory, biased or unverified, place it in a DATA / EVIDENCE GAP section. Do not guess or manufacture observations.

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- DMAIC charter
- problem and goal statements
- in/out-of-scope boundaries
- baseline and target fields
- stakeholder/team map
- initial risks and evidence gaps

Separate the response into CONFIRMED FACTS; OPERATIONAL DEFINITIONS; CALCULATIONS / OBSERVED PATTERNS; HYPOTHESES; RECOMMENDATIONS; DATA / EVIDENCE GAPS; RISKS / EXCEPTIONS; HUMAN DECISIONS REQUIRED.
Show formulas, denominators, filters, exclusions and assumptions whenever a calculation is used.
Do not treat correlation as causation, a small sample as population truth, or an average as evidence of process stability.
Where a statistical method is proposed, state the prerequisites and ask for qualified review if those prerequisites are uncertain.

LEAN SIX SIGMA CONTROL
Do not invent a baseline, target, savings figure or root cause. If the problem statement is not measurable, rewrite it as a draft and list the evidence needed before approval.

L — LIMITS, PRIVACY & LEADERSHIP APPROVAL
Do not independently authorize guest compensation, staffing or disciplinary action, pricing, budget release, safety acceptance, regulatory conclusions, technical return-to-service or final project benefits.
Do not expose unnecessary guest identity data, employee personal data, payment information, credentials, security-sensitive details or confidential contracts.
Statistical conclusions that affect material financial, safety, regulatory or employment decisions require review by the accountable qualified role.
The output remains a draft until the process owner verifies the evidence and authorizes the next action.

Expected output

DMAIC charter
problem and goal statements
in/out-of-scope boundaries
baseline and target fields
stakeholder/team map
initial risks and evidence gaps

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 02

#VOC to CTQ Converter

Translate verified guest, client or internal-customer needs into measurable critical-to-quality requirements without treating every comment as equally representative.

When to use it

Translate verified guest, client or internal-customer needs into measurable critical-to-quality requirements without treating every comment as equally representative.

Required inputs

approved VOC sources
sample period and population
verbatim themes or coded feedback
service promise/standard
available operational measures
segment/context definitions

Illustrative scenarioWorked example: VOC to CTQ Converter

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: Guests frequently say 'communication was slow' during maintenance cases; the team needs a measurable CTQ rather than a vague satisfaction statement.
Evidence: Check the supplied approved VOC sources, sample period and population, verbatim themes or coded feedback, service promise/standard, available operational measures. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the voc to ctq converter draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Translate verified guest, client or internal-customer needs into measurable critical-to-quality requirements without treating every comment as equally representative.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- approved VOC sources
- sample period and population
- verbatim themes or coded feedback
- service promise/standard
- available operational measures
- segment/context definitions

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- VOC theme table
- need-to-CTQ translation
- operational definition for each CTQ
- candidate measure and denominator
- evidence gaps
- validation questions

LEAN SIX SIGMA CONTROL
Keep stated guest needs separate from analyst interpretation. Do not infer population-wide importance from a small or biased sample.

Expected output

VOC theme table
need-to-CTQ translation
operational definition for each CTQ
candidate measure and denominator
evidence gaps
validation questions

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 03

#Pareto Analyzer

Identify the few categories contributing most to a defined hotel apartment defect, complaint, delay or rework burden using consistent categories and denominators.

When to use it

Identify the few categories contributing most to a defined hotel apartment defect, complaint, delay or rework burden using consistent categories and denominators.

Required inputs

clean event-level dataset or approved summary
category definitions
time period
denominator/exposure where relevant
cost or severity field if used
data-quality notes

Illustrative scenarioWorked example: Pareto Analyzer

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: The hotel apartment wants to know whether AC, plumbing, housekeeping, access or communication issues account for most repeat service-recovery workload.
Evidence: Check the supplied clean event-level dataset or approved summary, category definitions, time period, denominator/exposure where relevant, cost or severity field if used. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the pareto analyzer draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Identify the few categories contributing most to a defined hotel apartment defect, complaint, delay or rework burden using consistent categories and denominators.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- clean event-level dataset or approved summary
- category definitions
- time period
- denominator/exposure where relevant
- cost or severity field if used
- data-quality notes

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- ranked frequency table
- cumulative contribution
- cost/severity Pareto if justified
- category-definition warnings
- recommended focus areas
- questions for validation

LEAN SIX SIGMA CONTROL
Do not combine unlike categories merely to create an 80/20 story. State whether the Pareto is based on count, cost, time, severity or another measure.

Expected output

ranked frequency table
cumulative contribution
cost/severity Pareto if justified
category-definition warnings
recommended focus areas
questions for validation

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 04

#Root-Cause Hypothesis Builder

Generate testable root-cause hypotheses from a verified problem pattern without presenting plausible explanations as proven causes.

When to use it

Generate testable root-cause hypotheses from a verified problem pattern without presenting plausible explanations as proven causes.

Required inputs

validated problem definition
process map
stratified data
timeline
known changes
subject-matter observations
prior tests or findings

Illustrative scenarioWorked example: Root-Cause Hypothesis Builder

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: Room-not-ready delays are concentrated on high-turnover days; the team needs hypotheses about staffing, sequence, engineering blocks, late departures and inspection capacity.
Evidence: Check the supplied validated problem definition, process map, stratified data, timeline, known changes. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the root-cause hypothesis builder draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Generate testable root-cause hypotheses from a verified problem pattern without presenting plausible explanations as proven causes.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- validated problem definition
- process map
- stratified data
- timeline
- known changes
- subject-matter observations
- prior tests or findings

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- hypothesis register
- evidence for/against each hypothesis
- required test or observation
- confounders
- priority for investigation
- human SME questions

LEAN SIX SIGMA CONTROL
Every proposed cause must remain HYPOTHESIS until supported by evidence. Do not assign individual blame from outcome data.

Expected output

hypothesis register
evidence for/against each hypothesis
required test or observation
confounders
priority for investigation
human SME questions

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 05

#Fishbone Facilitator

Facilitate a structured cause-and-effect workshop that captures possible causes across people, process, technology, materials, environment, measurement and management controls.

Operating method first

Complaint Root-Cause Analysis

Define the standard, evidence and decision authority before using this prompt.

When to use it

Facilitate a structured cause-and-effect workshop that captures possible causes across people, process, technology, materials, environment, measurement and management controls.

Required inputs

problem statement
process scope
workshop participants
observations
known constraints
existing data
categories appropriate to the process

Illustrative scenarioWorked example: Fishbone Facilitator

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: A cross-functional team investigates repeat apartment-readiness failures involving Housekeeping, Engineering, Front Office and Inventory.
Evidence: Check the supplied problem statement, process scope, workshop participants, observations, known constraints. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the fishbone facilitator draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Facilitate a structured cause-and-effect workshop that captures possible causes across people, process, technology, materials, environment, measurement and management controls.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- problem statement
- process scope
- workshop participants
- observations
- known constraints
- existing data
- categories appropriate to the process

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- fishbone cause branches
- duplicate/overlapping causes
- evidence status
- questions to test causes
- parking-lot items
- next-step investigation list

LEAN SIX SIGMA CONTROL
Use the fishbone to organize possibilities, not to validate causes. Preserve minority observations and contradictions instead of forcing consensus.

Expected output

fishbone cause branches
duplicate/overlapping causes
evidence status
questions to test causes
parking-lot items
next-step investigation list

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 06

#FMEA Draft Assistant

Draft a process FMEA from a verified workflow by identifying potential failure modes, effects, causes and current controls for human scoring and action prioritization.

When to use it

Draft a process FMEA from a verified workflow by identifying potential failure modes, effects, causes and current controls for human scoring and action prioritization.

Required inputs

validated process steps
failure history
guest/safety/business effects
current prevention/detection controls
approved scoring scale
process owners
known regulatory/safety constraints

Illustrative scenarioWorked example: FMEA Draft Assistant

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: Management reviews the room-release process to identify how status conflicts, missed inspections, engineering blocks or access errors can fail before guest arrival.
Evidence: Check the supplied validated process steps, failure history, guest/safety/business effects, current prevention/detection controls, approved scoring scale. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the fmea draft assistant draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Draft a process FMEA from a verified workflow by identifying potential failure modes, effects, causes and current controls for human scoring and action prioritization.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- validated process steps
- failure history
- guest/safety/business effects
- current prevention/detection controls
- approved scoring scale
- process owners
- known regulatory/safety constraints

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- draft FMEA table
- failure modes by step
- effects and causes
- current controls
- unscored or human-scored severity/occurrence/detection fields
- recommended control questions

LEAN SIX SIGMA CONTROL
AI must not invent S/O/D scores, RPN thresholds, safety acceptability or risk acceptance. Qualified owners apply the approved scoring method and authorize actions.

Expected output

draft FMEA table
failure modes by step
effects and causes
current controls
unscored or human-scored severity/occurrence/detection fields
recommended control questions

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 07

#Cost of Poor Quality Analyzer

Structure an evidence-based cost-of-poor-quality model for hotel apartment defects, rework, refunds, wasted labor, downtime or lost capacity without fabricating financial benefits.

Operating method first

Define the standard, evidence and decision authority before using this prompt.

When to use it

Structure an evidence-based cost-of-poor-quality model for hotel apartment defects, rework, refunds, wasted labor, downtime or lost capacity without fabricating financial benefits.

Required inputs

defect/rework volumes
Finance-approved cost assumptions
labor time
refund/compensation records
downtime or out-of-order data
period and denominator
exclusions and uncertainty

Illustrative scenarioWorked example: Cost of Poor Quality Analyzer

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: The property wants to estimate the monthly cost of repeat recleans, maintenance revisits and guest compensation linked to a recurring readiness defect.
Evidence: Check the supplied defect/rework volumes, Finance-approved cost assumptions, labor time, refund/compensation records, downtime or out-of-order data. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the cost of poor quality analyzer draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Structure an evidence-based cost-of-poor-quality model for hotel apartment defects, rework, refunds, wasted labor, downtime or lost capacity without fabricating financial benefits.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- defect/rework volumes
- Finance-approved cost assumptions
- labor time
- refund/compensation records
- downtime or out-of-order data
- period and denominator
- exclusions and uncertainty

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- COPQ categories
- calculation table
- verified vs estimated costs
- sensitivity range
- data gaps
- Finance-review questions

LEAN SIX SIGMA CONTROL
Label every assumption. Do not classify revenue opportunity as realized savings, double-count costs, or claim benefits until Finance validates the method.

Expected output

COPQ categories
calculation table
verified vs estimated costs
sensitivity range
data gaps
Finance-review questions

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 08

#Process Capability Review Planner

Plan a valid capability review for a stable, measurable hotel apartment process and determine whether capability statistics are appropriate before calculating them.

When to use it

Plan a valid capability review for a stable, measurable hotel apartment process and determine whether capability statistics are appropriate before calculating them.

Required inputs

CTQ/specification limits
measurement definition
time-ordered observations
measurement-system information
process segmentation
stability evidence
sample size

Illustrative scenarioWorked example: Process Capability Review Planner

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: A hotel apartment wants to assess whether check-in completion time consistently meets a defined service specification rather than merely reporting an average.
Evidence: Check the supplied CTQ/specification limits, measurement definition, time-ordered observations, measurement-system information, process segmentation. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the process capability review planner draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Plan a valid capability review for a stable, measurable hotel apartment process and determine whether capability statistics are appropriate before calculating them.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- CTQ/specification limits
- measurement definition
- time-ordered observations
- measurement-system information
- process segmentation
- stability evidence
- sample size

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- capability-readiness assessment
- data/stability checks
- appropriate capability approach
- stratification plan
- warnings against invalid Cp/Cpk use
- human statistical review questions

LEAN SIX SIGMA CONTROL
Do not calculate or interpret Cp/Cpk/Pp/Ppk unless the prerequisites and supplied data support it. Distinguish specification limits from management targets and control limits.

Expected output

capability-readiness assessment
data/stability checks
appropriate capability approach
stratification plan
warnings against invalid Cp/Cpk use
human statistical review questions

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 09

#Control Plan Builder

Convert an approved improvement into a sustainable hotel apartment control plan with measures, ownership, frequency, reaction limits, evidence and escalation.

Operating method first

Define the standard, evidence and decision authority before using this prompt.

When to use it

Convert an approved improvement into a sustainable hotel apartment control plan with measures, ownership, frequency, reaction limits, evidence and escalation.

Required inputs

approved future-state process
validated CTQs/KPIs
known failure modes
control method
owners
review frequency
reaction/escalation rules
document/SOP changes

Illustrative scenarioWorked example: Control Plan Builder

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: After improving the room-release gate, the hotel apartment needs a weekly control plan to detect missed inspections and repeat readiness defects.
Evidence: Check the supplied approved future-state process, validated CTQs/KPIs, known failure modes, control method, owners. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the control plan builder draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Convert an approved improvement into a sustainable hotel apartment control plan with measures, ownership, frequency, reaction limits, evidence and escalation.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- approved future-state process
- validated CTQs/KPIs
- known failure modes
- control method
- owners
- review frequency
- reaction/escalation rules
- document/SOP changes

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- control-plan table
- metric definitions
- owner and frequency
- reaction plan
- evidence/record requirement
- handover to SOP/training/audit

LEAN SIX SIGMA CONTROL
Do not invent control limits or reaction thresholds. Use only thresholds approved by the process owner or statistically validated through the defined method.

Expected output

control-plan table
metric definitions
owner and frequency
reaction plan
evidence/record requirement
handover to SOP/training/audit

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Prompt 10

#Kaizen Opportunity Prioritizer

Prioritize small hotel apartment improvement opportunities using evidence, guest impact, effort, risk, reversibility and owner capacity without turning an AI ranking into management approval.

When to use it

Prioritize small hotel apartment improvement opportunities using evidence, guest impact, effort, risk, reversibility and owner capacity without turning an AI ranking into management approval.

Required inputs

improvement backlog
problem evidence
guest/business impact
estimated effort
risk/safety implications
dependencies
owner capacity
strategic priorities

Illustrative scenarioWorked example: Kaizen Opportunity Prioritizer

Operational teaching scenario, not a documented incident. Uncited figures and outcomes are illustrative assumptions.

Situation: Example: Operations has 18 improvement ideas across housekeeping, maintenance, arrivals and long-stay service and needs a transparent pilot sequence.
Evidence: Check the supplied improvement backlog, problem evidence, guest/business impact, estimated effort, risk/safety implications. Treat scenario inputs as assumptions until confirmed against approved records.
Decision: Decide whether the inputs are complete and the task is authorised. If not, request the missing information before using the prompt.
Action: Prepare the kaizen opportunity prioritizer draft from the checked inputs; keep unresolved facts and required approvals visible.
Verification: Compare the draft with the source records and expected outputs. The named accountable owner must verify and approve it before live use.

Copy-and-Paste Template

Complete prompt

O — OPERATIONAL OBJECTIVE & CONTEXT
Objective: Prioritize small hotel apartment improvement opportunities using evidence, guest impact, effort, risk, reversibility and owner capacity without turning an AI ranking into management approval.
Property type/location: [Insert confirmed property and jurisdiction]
Process/department: [Insert]
Project phase: [Define / Measure / Analyze / Improve / Control]
Study period and population: [Insert]
Decision this output supports: [Insert]

T — TRUSTED INPUTS & SOURCES OF TRUTH
Use only supplied, current and approved hotel apartment records.
Required inputs:
- improvement backlog
- problem evidence
- guest/business impact
- estimated effort
- risk/safety implications
- dependencies
- owner capacity
- strategic priorities

E — EXPECTED OUTPUT, EXCEPTIONS & EVIDENCE
Return:
- prioritized opportunity matrix
- quick-win candidates
- do-not-rush items
- evidence gaps
- dependency map
- recommended pilot sequence

LEAN SIX SIGMA CONTROL
Safety, legal, privacy and regulatory issues must not be deprioritized because they score poorly on convenience or ROI. Final prioritization belongs to accountable management.

Expected output

prioritized opportunity matrix
quick-win candidates
do-not-rush items
evidence gaps
dependency map
recommended pilot sequence

Human verification

Professional hotel apartment trainer’s note

Keep definitions, denominators, assumptions and unresolved evidence visible. The accountable process owner must verify the analysis before any operational decision.

Connect this guide to your next step

Continue with related methods and the wider series.

Put this article into practice

Use the prompts to structure DMAIC, VOC, Pareto, cause analysis and control plans using evidence for human review.
Verify the supplied facts and record any missing evidence before acting.
Name the accountable owner and confirm the decision or approval limits.
Test the result in the operating context and retain the verification record.

Your next step

Supply the required inputs, copy the complete prompt and verify the output before using it in the operation.

Apply DMAIC Project Charter Builder