Skip to content
View in the app

A better way to browse. Learn more.

Benchmark Six Sigma Forum

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

Ayomide

Members
  • Joined

  • Last visited

Everything posted by Ayomide

  1. On paper, workforce scheduling looks straightforward; match the number of people to the expected workload. But anyone who has managed it in a volatile market knows it rarely plays out that way. In my own environment, it’s one of the biggest struggles. The challenge is this: we build production schedules weeks in advance, based on forecasts that seemed right at the time. Labor is then locked in, often through external contractors who expect firm commitments. But when demand suddenly drops, you can’t just scale people down immediately. Shifts get cancelled, but the company still ends up paying part of that cost because the labor was already booked. So, the real headache isn’t just assigning shifts, it’s how much volatility you’re exposed to, and the money lost when plans don’t match reality. That’s why I sometimes think AI scheduling on its own doesn’t solve the real issue. If the demand forecast is wrong, the schedule will also be wrong. What would make more sense is if AI could give us better forecasts in the first place. Not just from sales data, but by pulling in other signals, economic changes, customer behavior shifts, even political uncertainty in our region. A more accurate forecast makes scheduling less chaotic. That said, AI can still help with the scheduling side if it considers more than just filling hours. For example: Fairness to employees. When demand drops, the same set of people shouldn’t always lose their shifts. A system could spread that impact, so everyone shares the burden. Skills. Not every operator can handle every line. Scheduling has to reflect actual skills, not just bodies filling spaces. Legal and compliance issues. Overtime, rest breaks, and labor laws need to be respected, no matter how clever the schedule looks. Flexibility. Instead of locking everything in, the plan should allow a small pool of standby workers who can cover sudden swings without driving costs up. From what I’ve seen, forecasting accuracy reduces the shock, and scheduling then becomes more of a fine-tuning exercise rather than a fire drill. Efficiency matters, yes, but people matter too. If workers feel the system only cares about saving money, morale falls, and attrition rises. But if it’s seen as fair, shifts are shared, preferences are respected where possible, and decisions are transparent, then you get both smoother operations and trust from the workforce.
  2. For me, the real problem with AI in customer service isn’t that it exists, it’s that it often feels like you’re talking to a robot that doesn’t really “get” what you’re saying. One situation that sticks with me is when I had issues with my bank’s mobile app. I called support, and the first thing I got was the automated AI system. The problem I had wasn’t one of the “standard” ones, so it kept pushing the same canned answers back at me. After a few minutes of frustration, I finally got transferred to a human agent. The interesting thing is, even though that person couldn’t immediately fix the issue, I left the call feeling more relaxed, simply because they asked me the right questions, let me explain everything, and made me feel understood. That human part is what AI still struggles with. If AI is going to make interactions feel personal, it has to do more than spit out quick responses. It needs to listen the way people listen. That means asking clarifying questions before offering a solution. It also means learning from real conversations, not just reading scripts, but actually picking up how humans talk, where they pause, when they use humor, and how they handle frustration. If AI could “sit in” while humans solve problems, it would learn that flow and stop sounding so generic. Amazon’s customer service is actually a good example of where this balance already works. When you reach out, the AI doesn’t try to solve everything on its own. It takes the basic information like your order number or what type of problem you’re having, and then smoothly hands you to a person if the issue needs more attention. Sometimes it even comes back later in the conversation to wrap things up, like confirming a refund. As a customer, you don’t really notice the handoff, because it feels seamless. And that’s the key: it feels like someone is actually paying attention to you, not just pushing you through a system. If I were to sketch it out, it’s kind of like this: Customer explains problem ---> AI listens + asks clarifying Qs ---> Human rep takes over if needed<--- AI can return for simple follow-up (refunds, updates) The point is, personalization doesn’t mean AI has to act exactly like a person. It means the customer walks away feeling like they were heard. If the AI can do that by clarifying, by knowing when to step aside, and by sounding less like a script, then the interaction will feel personal and trustworthy. Otherwise, people will just keep waiting for the human rep, like I did with my bank.
  3. I recently worked on a project where we built what we called a CO-CEO AI agent for a marketing company. The idea was simple: instead of treating the AI as a background tool, we brought it into the decision-making process almost like another executive. Its main job was to help the CEO design marketing strategies for different clients. Now, here’s the twist. We didn’t just let the AI spit out strategies in isolation. It was invited to client meetings, not literally of course, but through structured prompts where the full context of the client’s business, challenges, and goals was fed in. That way, its recommendations weren’t generic “playbook strategies,” but tailored to the actual discussion the leadership team was having. That made it much more of a trusted advisor than a black-box machine. From this project, I learned that there are two layers to making AI advice truly useful and trustworthy for leaders: 1. Where It Should Assist Pattern spotting across campaigns: Leaders don’t always have the time to compare 50 different client reports. The AI could highlight trends (e.g., “clients in retail are seeing 20% higher engagement when campaigns run mid-week”). Scenario testing: Instead of one “best” strategy, the AI could lay out three options: low-risk, high-growth, or balanced. This gave the CEO choices rather than a single directive. Speed on background research: Before walking into a client strategy session, the AI could summarize competitor campaigns, past results, and market conditions in minutes. These are areas where AI’s scale and speed give leaders an advantage without replacing their judgment. 2. Checks to Keep It Reliable Context gatekeeping: The AI was only as good as the context it had. We made it a rule that client objectives and constraints must be captured first (almost like a briefing note) before the AI gave advice. No context, no strategy. Audit trail of reasoning: Every recommendation had to come with a short rationale, “this works because past campaigns in similar industries showed X, Y, Z.” This gave the CEO confidence in the “why,” not just the “what.” Version control for prompts: As we refined how we asked the AI questions, we tracked changes. For example, when we shifted from “generate campaign ideas” to “act as a CMO and propose three strategies with risks and trade-offs,” we documented it. That way, if a change caused worse outputs, we could roll back quickly. Human override always on: The AI was never treated as final authority. The CEO still made the call, but with stronger input in less time. Honestly, what made this whole setup work wasn’t the AI being “super smart.” It was the way we used it. We never treated it like it was going to run the company or make the final call. Instead, it was more like a second set of eyes, someone in the room who could throw out a few options, show the risks, and spot patterns the rest of us didn’t have time to see. The clever part wasn’t the output, it was the process: making sure it only answered once we’d given it the right context, tracking how we asked questions so we didn’t lose improvements, and always keeping a paper trail of its reasoning so it didn’t feel like magic. At the end of the day, the CEO still made the decisions. The AI just made those decisions faster and more informed. That’s really the trick to building trust. You let the AI contribute, but you don’t hand over the steering wheel. It’s not there to replace judgment, it’s there to make good judgment easier.
  4. Bias in AI isn’t some abstract problem as it shows up in small, practical ways that most people don’t notice until it’s already causing a problem. I’ll give you an example from the kind of work I’ve seen. In service delivery, we often deal with maintenance requests or customer cases that need to be prioritized. Now imagine if the AI is trained mostly on past data. If, historically, tickets raised by one team or location were often resolved slowly, the AI might start to assume those cases are “less urgent.” Before long, those teams will always find themselves at the back of the queue. The irony is the delay might have been caused by resource issues or the way the forms were filled out, not because their problems were any less important. That’s how bias creeps in; quietly, and it reinforces itself over time. People on the ground start to feel ignored, managers get a distorted picture of performance, and eventually trust in the system erodes. For me, the way to handle this is to think of it in three steps: how you design the system, how you test it, and how you keep an eye on it after it’s live. In design, you can reduce the risk by being intentional with the criteria. Don’t just ask the AI “which case is important.” That leaves too much room for bias. Ask it to sort based on specific, objective measures: downtime cost, safety impact, compliance deadlines. The way you phrase the prompt matters a lot here. It’s like training a new employee, if you give vague instructions, they’ll pick up the wrong habits. In testing, don’t just look at overall accuracy. You’ve got to watch for patterns. Run “what if” scenarios, like two tickets with the same severity logged by different shifts, and see if the AI treats them fairly. I’ve found that having people from different teams review sample outputs helps because each group notices different red flags. In monitoring, you can’t just set and forget. Build in transparency. For example, if the AI deprioritizes a ticket, it should also give a one-line reason: “low safety risk, low downtime impact.” That way, if someone disagrees, they can challenge the logic. And just as importantly, track whether one group of users keeps getting the short end of the stick. If you see patterns, adjust the flows or roll back to an earlier version. Here’s a rough sketch of how I see it working in practice: Biased Data → Biased Prompts → Biased Outputs Balanced inputs Neutral wording Rationale + audits ---------------- Continuous Loop ---------------- Breaking the cycle isn’t about “fix it once.” It’s more like continuous improvement in operations. You don’t assume the process is perfect, you keep testing, you adjust, you listen to feedback, and you document every change, so you know what worked and what didn’t. If I’m honest, bias will never be gone completely, because humans build the systems and humans carry bias. But if you treat AI flows with the same discipline as any other critical process, version control, testing edge cases, and constant monitoring, you stop bias from quietly taking root and repeating itself at scale.
  5. The black box vs glass box debate reminds me of driving a car. Most drivers don’t want to know how the transmission works; they just want to hit the gas and get moving. But when the mechanic pops the hood, they expect full detail: what failed, why it failed, and how confident they are in the fix. AI is no different. The way you design prompts decides whether you’re handing people the steering wheel or giving them the service manual. That’s why prompt engineering is so powerful. If you just say, “why is the machine failing,” you’ll get a vague black-box answer. If you say: “act like a packaging engineer, explain three likely causes, show your reasoning, and give a confidence score”, suddenly you’ve turned the same AI into a glass box. From my experience, there are seven simple prompt-engineering levers that decide how much transparency you get: Clarity – Be specific in the ask. Context – Set the scene (industry, process, audience). Role assignment – Tell the AI who it is. Step-by-step reasoning – Don’t just ask for answers, ask for the logic. Structure – Tables, bullet lists, confidence percentages. Examples – Show what “good” looks like. Iteration – Test, tweak, and refine just like Continuous Improvement work. The line between explainability and simplicity isn’t fixed. For operators, I keep prompts tuned for speed: one likely cause, one action. For leadership, I dial up transparency: full rationale, trade-offs, and scores. Same AI, same data, but by engineering the prompts, you control the “glass tint” of the box. So, for me, it’s not really black vs glass. It’s about building adjustable transparency into the flow. AI should be like a dashboard: quick lights for speed, and detailed readouts when you need to pop the hood. Prompt engineering is what makes that possible.
  6. When we first started using AI to track production downtime patterns, I built a simple flow that pulled operator inputs and generated quick insights for the shift leads. At one point, I decided to tweak the prompt that asked operators to describe the issue, just to make issues clearer and easy to understand by the technical team. I thought it was an improvement. A week later, my phone was buzzing during a site visit because the reports coming out of the system suddenly had big gaps. Turns out my “clarity” change made operators give shorter answers that didn’t have enough detail for the analysis to work. Since then, I’ve treated AI flows exactly the way I treat any process change in manufacturing: I save every version before I touch it. Not just the file but a quick note on what I changed and why. I run the new version in a controlled test with a small team, not the whole plant. If it performs better on the KPIs we care about like accuracy, speed, usability, then it graduates to live. If it doesn’t, I roll it back in minutes because the last good version is sitting in my folder. I also keep two environments: the stable one for what’s proven, and a “playground” for experiments. That way, I can test bold ideas without worrying about disrupting a live process. It’s the same mindset I use in CI projects: measure first, change deliberately, and always keep the option to go back. With AI flows, that discipline makes the difference between steady improvement and a messy guessing game.
  7. In Lean Six Sigma, we have seen most of the time that implemented process improvement projects are not sustainable because of improper handover to process owners. Further findings have shown that most Lean Six Sigma Green/Blackbelt professionals think that handover is when the project has been done independently of the process owners and process team members and just requires that the finished work be handed over to the final users without having carried them along from the project initiation phase. Project handover starts when the project was initiated and this means in the selection of the team members who are to carry out the project. A conscious integration of the entire team along side the process owner into the ideation, analysis and execution of the final improvements is what ensures that improvements are sustainable. The sustainability of a project starts the moment the project is handed over to the process owner and the team members with clear explanations of control measures and things to check out for, steps to take if things go out of control but only a process owner who has been involved in a project from the word go is able to carry out the control measures and monitor from time to time. Now in the space of AI Solution handover for long term success, we have to understand some major facts: 1. As much as AI is no longer new, we are also aware that based on a lot of research, frequent changes are being made in the AI space, which could give better solutions to existing problems. 2. We as AI solutions architects should shift from the mindset of just creating solutions just for end users but understand that for every solution created there is a need to create a proper change control for the new solution. This make everyone aware of what changes are being implemented, how it affects them and what role they play in the change or project. 3. Proper project documentation is required in the handovger process which shows the step by step process from project initiation to execution. This ensures that even after anyone who was involved in the project leaves the system, anyone can go through the handover document and understand the change and make adjustments if need be. This means that for long term success; 1. We have to be very flexible to the changes that are happening. 2. Proper team selection is required for long term success as they have to be involved from the very beginning. 3. Proper change control has to be initiated for such projects to make everyone understand the change and the role they are to play to ensure sustainability and long-term success. 4. Proper project documentation for reference.
  8. There is no doubt to the fact that AI Agents live and breathe on data fed to it which means garbage in garbage out. Data integrity is key to ensuring that AI agents are able to right solutions to problems. The first loop is therefore to ensure that data been fed to these agents are being cleaned before they are fed in. Now to the next phase after the data has been fed to these agents, they get better over time which is based on the training using available data over time. In cases where agents go off track, it is the responsibility of the builder to give accurate feedback to the agents where it must have gone off track or given wrong information so as to document that mistake as a data point and ensure it is stored in its repository to prevent reoccurrence. Most often than not people ignore the errors in AI Agent's responses due to several reason and just copy the outcomes without reviewing for mistakes and errors. If these errors are accepted, it builds the confidence level of the AI Agents into believing that responses provided are 100% correct and stores them as data points as well which would be used to answer and proffer solutions to future problems and then the loop continues. In other to prevent this from happening, first is for AI Agent builders to infuse the feedback look asking if the solution provided meets the users need ot there are specific areas where some changes need to be made. Some can be built in such a way that the AI Agent asks more clarifying questions to allow the user give proper context to help the AI Agent proffer the best solution through contextual framing. Also, feedback rating in my opinion isn't the best way to help the Agent improve on responses or solution but proper feedback on areas where the agent hasn't provided right answers, provided longer responses than needed, the use of words that doesn't make things sound real and a host of other are super important if we aim to help the AI Agents improve based on real feedback. In other words, as much as we want AI Agents to move from very generic responses when proffering solutions to out problems, we should equally be ready to shift away from giving generic feedback to AI Agents as these serves as data points for them to reference is they are to improve and give better outputs.
  9. For me personally, in several of my past prompts, especially when crafting scripts for my video contents as a content creator, or drafting a LinkedIn post or reflections on an event or workshop I attended, I have noticed ChatGPT would often go off track: too generic, too wordy, or just not sounding like me (Using big English words which is unlike me because my vocab isn't that great lol). One early example was when I asked for a LinkedIn post about my first time speaking on a panel. I wanted it to sound honest and personal, but the AI kept giving me something that felt too polished or like it came from a template. I had to keep replying: “This doesn’t sound like me,” or “This is too generic" or "This sounds cliche" Another time was when I asked for a birthday message to a friend and wanted it to sound like me. I was clear that it shouldn’t bring in generic birthday messages and big words, but then, it still found ways to bring it in. It took several tries to get it right, I had to be more specific and say, “Avoid anything this and that, and just keep it sincere and light.” One major shift happened when I learned to guide ChatGPT with better instructions after taking the CAISA training which had a section on prompt engineering. Instead of long, open-ended prompts, I now break things down: I start with the tone, then the structure, then the exact outcome I want, giving it proper context. Also, learning about temperature settings helped. When I need it to stay focused, like writing a formal email or drafting a workshop plan or even during complex conversations, I reduce the temperature, so it doesn’t get too creative. And when I noticed it repeating itself or giving extra fluff, I started using token and top-p adjustments to limit that. Over time, my prompts have become clearer and more direct, and the ChatGPT started responding better. I still have to correct it sometimes, but now I understand why it goes off-track and how to pull it back.
  10. Using myself as a practical example pre my knowledge of prompt engineering and my use of ChatGPT, I have used AI to write content scripts, respond to emails, draft the flow of strategy sessions for a business leader's workshop, design SOPs, training modules, and presentation scripts in a global manufacturing context. I can tell for a fact that the results I have gotten post my knowledge of prompt engineering and design shows how prompt design can elevate or limit the outcome. My initial prompts was something like "Create an SOP for the Logistics team" or "What caused Line 2's downtime yesterday" but has now evolved into "on yesterday’s downtime on Line 2, using available sensor logs, operator notes, and maintenance history, identify the most probable root causes and suggest low-cost, high-impact fixes relevant to skincare batch making process" or "Create a logistics SOP for a skincare manufacturing plant in Nigeria, including job grade responsibilities, escalation paths, tool access levels, and cross-functional dependencies.” I think the prompts given to an AI model is critical because it determines whether the output is surface-level or genuinely actionable and within the context of the problem you are trying to solve. The improvement didn’t just help me get better results; it helped the AI model understand my context more deeply. In other words, better prompts led to smarter AI support which in turn leads to better decision making.

Account

Navigation

Search

Search

Configure browser push notifications

Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.