Launch Readiness and Scope Negotiation

Good morning, everyone. Thanks for making time at short notice. Before we get started, could we quickly confirm who is joining from each team? I am Maya from Product, and I will chair today's launch readiness meeting. Our goal is to decide whether the customer portal is ready for a limited release next Thursday. We have twenty minutes, so please flag anything that requires a decision rather than simply giving us a general status update.

Daniel here from Engineering. I am covering both the development work and the release checklist today. Priya, our quality lead, cannot join because she is investigating a separate incident, but she has shared her test results with me. I can answer most questions, and I will take anything I cannot resolve back to her after this meeting. From our side, the main point is a remaining issue with account permissions, which I will explain shortly.

Olivia from Sales is here. I have spoken with the five customers who volunteered for the pilot, and all five are still interested. Two have asked whether their regional managers can access the same reports as their headquarters teams. I have not promised that feature yet, because I wanted to check with Engineering first. I would also like us to agree on the wording we use with customers if we decide to narrow the scope of the first release.

Jun from Customer Support is on the call as well. Our team has finished the draft support guide, but we still need screenshots of the final interface. We can support five pilot customers with our current staffing, provided the launch happens during our normal support hours. I would prefer not to introduce the portal late in the evening. If something goes wrong with account access, we need an engineer available while our agents are speaking with the customer.

Great, we have all four teams represented. Let me set the context so that we are working from the same assumptions. Today is Thursday, October eighth. The proposed pilot date is October fifteenth, and this is a controlled release for five existing customers, not a public launch. No one is asking us to support the entire customer base next week. By the end of this call, we need a clear scope, a release decision framework, and named owners for the outstanding actions.

To give you the headline first, the core reporting features are ready. Customers can log in, view their monthly activity, and download a summary. We have tested those journeys with the same account configuration used by the pilot customers. The remaining defect appears when a headquarters administrator invites a regional manager and then changes that person's permissions. In some cases, the manager continues to see a report that should no longer be available. That is a security concern, even though it affects a fairly specific workflow.

Thank you for being direct about that. From a commercial perspective, there is value in keeping the pilot date because the customers have reserved time for onboarding. However, I do not want to protect a date at the expense of trust. Could you clarify whether this issue affects the default account setup, or only customers who enable regional access? That distinction matters when we explain our options. If the default setup is safe, a smaller pilot may still give us useful feedback without exposing customers to the defect.

It only affects the regional access feature, based on the tests we have completed so far. That said, I would be careful about calling the default setup completely safe until we finish the regression tests. The proposed workaround is to disable regional invitations for the pilot and allow only one headquarters administrator per customer. This removes the affected workflow rather than trying to manage it through instructions. We can implement that restriction today, but we still need an independent check that it cannot be bypassed.

That restriction would also make onboarding easier for Support, although we should not treat convenience as the reason for the decision. One administrator gives us a clear contact at each customer, and it reduces the number of permission questions during the first week. We would need a precise explanation of what the pilot includes and excludes. Otherwise, an agent may accidentally tell a regional user to ask for an invitation, which would create confusion even if the invitation button has been disabled.

Let us align on the decision we are actually making. We are not deciding today whether regional access is a worthwhile feature; it clearly is. We are deciding whether the restricted pilot can meet our quality standards by next Thursday. I suggest we separate essential release criteria from features that can follow later. Essential criteria include reliable login, correct report access, a tested rollback procedure, and a support guide that matches the released product. Does anyone see another requirement that belongs on that list?

I would add explicit customer consent to the reduced scope. The two customers who requested regional access may still agree to participate, but we should ask rather than assume. For them, the main benefit is sharing information across locations, so headquarters-only access changes the value of the trial. I can contact both customers tomorrow morning and explain the restriction. If either customer declines, I recommend continuing with the remaining volunteers instead of recruiting a replacement at the last minute and rushing the onboarding process.

That sounds reasonable. I also want to put a number on the engineering work so we can discuss the trade-off properly. Disabling invitations and completing the restricted-account tests should take about two working days. Fixing the underlying permission problem and testing every combination could take four to six working days. Those estimates are not commitments yet. We have identified the likely cause, but we have not confirmed it. If we try to include the full feature next Thursday, we would have very little time left for a meaningful release review.

I hear the schedule pressure, but I would like to challenge one assumption. Are the restricted pilot and the permanent fix competing for the same engineers, or can they move forward in parallel? If the workaround takes everyone away from the real fix, we might be creating more work without much learning. On the other hand, if one engineer can handle the restriction while another investigates the defect, the pilot may be a sensible way to gather feedback on the reporting experience. What would the staffing look like?

We can run the two workstreams in parallel, with one important dependency. I can implement the restriction, and Priya can verify the account behavior. Another engineer, Sam, can investigate the permanent fix. However, Priya will need to review Sam's tests before we enable regional access later. We should therefore avoid promising a date for that second release today. I can give an updated estimate on Monday once Sam has reproduced the defect reliably and checked whether the same issue exists in related services.

Can I raise a concern about the customer experience? If a customer logs in and sees a disabled invitation button without an explanation, they may think their account is broken. Could we hide the button entirely and include a short note in the welcome email explaining that the pilot supports a single administrator? I am not asking for a complicated new screen. I am asking for a consistent message across the product, the email, and our support guide, so customers do not receive three slightly different explanations.

I agree with Jun on that point. I would avoid describing the restriction as a temporary technical limitation in the first sentence of the email, because that language could sound evasive. We can say plainly that this pilot focuses on the headquarters reporting workflow and that regional access is outside its current scope. If customers ask why, we should answer honestly that further validation is needed before that feature is released. We should also make it clear that participation is optional and that feedback will influence future improvements.

That gives us a practical path forward. Before we settle on it, let us consider the downside. With only headquarters users, we will learn less about collaboration between locations. Our success measures need to reflect that smaller scope. We should measure whether administrators can complete the reporting tasks, whether the reports are understandable, and how much support they need. We should not claim that the pilot validates regional collaboration. Olivia, would those results still be useful for the customer conversations your team expects to have later this month?

Yes, provided we explain the limits of the evidence. Several customers are primarily concerned about the time they spend preparing monthly reports, so a headquarters pilot addresses a real need. I would like to collect a short baseline before onboarding: how long the current process takes, who prepares the report, and which information is hardest to find. Then we can compare the experience after one week. That is more credible than asking whether people generally like the portal, and it should give Product something specific to improve.

One final point from Engineering: disabling the button is not sufficient on its own. We also need to enforce the restriction on the server, because users can sometimes reach an endpoint without using the visible interface. I will include that in the implementation and ask Priya to test direct requests as well as normal navigation. If any access-control test fails, the release is a no-go. I do not think that should be open to negotiation based on the number of customers or the commercial importance of the pilot.

I support that release condition. For a rollback, please tell us exactly what customers would experience. Would they lose access to the new portal while their existing reporting process remains available? If so, Support can explain the fallback confidently and help customers return to their usual workflow. We should prepare that message before launch day, even if we never use it. I would also like a named engineering contact and a backup contact, because an escalation plan is only useful if someone actually responds when we need help.

Let me summarize where we have landed. We will prepare a headquarters-only pilot for October fifteenth, subject to the release criteria being met. Regional invitations will be unavailable in both the interface and the server. Sales will confirm customer consent, and we will proceed with the customers who accept the narrower scope. We will not announce a date for regional access until Engineering has a reliable estimate. This is a conditional plan, not permission to release regardless of the test results. Have I captured everyone's position accurately?

Yes. I will own the technical restriction and provide final interface screenshots by Friday, October ninth, at three p.m. Korea time. Priya will own the independent verification, with results ready before our Monday checkpoint. Sam will continue investigating the permanent fix. For launch-day escalation, I will be the primary engineering contact, and Sam will be the backup. The existing reporting process will remain available if we disable the portal, and I will document and test that fallback before the final release review.

I will own customer communication. Tomorrow morning, I will contact the two customers who asked for regional access, then confirm the final participant list by four p.m. Korea time. I will share the welcome email draft with Jun and Maya before sending it. The email will state the pilot scope, the optional nature of participation, and the fallback reporting process. I will also collect the baseline information we discussed, but I will keep that questionnaire short so it does not become a barrier to joining the pilot.

I will update the support guide after the screenshots arrive on Friday. Our internal training session is scheduled for Monday afternoon, so I need the release scope to remain stable after the Monday checkpoint unless a serious defect changes the decision. I will add the escalation contacts and the rollback message to the guide. Before Thursday's release, I will check that an agent can walk through the onboarding process using a test account. That will help us catch unclear instructions rather than only checking whether the document looks complete.

I will own the release checklist and the pilot success measures. I will circulate a written recap today so that the decisions are not buried in meeting notes. Each action will have an owner, a deadline, and a clear completion condition. If a deadline slips, please flag it early rather than waiting for the next meeting. We can adjust the plan when we have information; we cannot manage a risk that stays invisible. Our final go or no-go review will be Wednesday, October fourteenth, at four p.m. Korea time.

Before we close, can we confirm who makes the final release decision? I want to avoid a situation where Sales tells customers that the pilot is confirmed while Engineering still considers it conditional. My understanding is that Maya will communicate the decision after Wednesday's review, with Engineering confirming that the technical criteria are met and Support confirming operational readiness. Until then, I will describe October fifteenth as the planned pilot date. If that wording is acceptable, I can use it consistently in every customer conversation this week.

That is exactly right. I will communicate the final decision, and we will require both technical and operational sign-off. Let us schedule our next checkpoint for Monday, October twelfth, at ten a.m. Korea time, for twenty minutes. Daniel, please bring the test results and the updated estimate for regional access. Olivia, bring the confirmed customer list and any concerns about the reduced scope. Jun, bring the revised guide and any unanswered onboarding questions. I will send the invitation with those preparation items immediately after this call.

Monday at ten works for Engineering. One small clarification: if Priya finds an access-control failure before Monday, I will inform this group as soon as we understand its impact. I will not wait for the checkpoint to raise it. The same applies if the proposed restriction turns out to affect the core reporting workflow. In either case, we may need to revisit the launch date rather than adding another workaround. I appreciate having that threshold clear now, because it gives the team a definite basis for escalating concerns.

That works for Support too. I will reserve coverage for Thursday, October fifteenth, from nine a.m. to noon Korea time, and we can confirm the exact release time during Wednesday's review. Please keep us in the loop if the customer list changes, because we prepare an account-specific checklist for each participant. I will also remind our agents that regional access has not been promised. That should prevent well-intentioned answers from creating commitments that Product and Engineering have not agreed to deliver.

Excellent. We have a conditional pilot plan, clear release gates, and owners for the next steps. The main risk is still account access, and the response is to verify the restriction before release rather than rely on customer instructions. I will send the recap and the Monday invitation today. Please reply if the written summary misses a decision or assigns an action incorrectly. Otherwise, we will use that summary as our shared reference. Thanks, everyone. Let us reconvene on Monday with the evidence we need to make the next decision.