Defining a Joint Customer Pilot and Partnership Exit Rules

Thanks for joining the partnership workshop this Sunday, October eleventh. We arranged today's session around the customer team's availability, and I appreciate everyone making room for it. I am Clara from Aster Partnerships. Dev and Sanjay represent our delivery team, Elise leads Beacon Alliances, and Joon represents Beacon Customer Advisory. Could you confirm that you have the joint pilot outline? Our immediate decision is whether we can offer one customer a coherent pilot, with clear responsibilities and a sensible end point. I would like us to leave with an offer both companies can explain consistently, including what happens if the pilot does not work.

I have the outline. Beacon brought the customer opportunity, and our advisers have worked with their regional directors for two years. We want to combine your workflow platform with our process coaching, but the customer should not have to manage the boundary between us. My main concern is customer ownership. If the pilot succeeds, I do not want Beacon to become an introduction service while Aster takes over the relationship. Equally, I recognize that your team needs direct access to users to support the platform. We should discuss that tension openly before putting a joint logo on the proposal.

I have the same document. Aster Delivery can configure the pilot workspace, train users on the platform, and investigate technical issues. We need access to the customer's process owners because configuration questions often involve how work actually moves between teams. If every question passes through two account managers, the pilot could spend its first month waiting for clarifications. However, direct access should not mean that our engineers start discussing an unrelated subscription with someone they happen to meet. I can define a contact protocol that distinguishes delivery conversations from commercial conversations.

The customer wants to reduce missed handoffs between its installation planners and field coordinators. Their current process relies on email and a weekly status call, so ownership sometimes changes without the next person knowing. They are interested in the combined offer because software alone has not fixed the behavior, and coaching alone has not made the work visible. I will lead the customer workshops and help the teams agree on practical working rules. My concern is that we could describe the pilot as a transformation and then measure only login activity. We should define the operational change before deciding which metrics look convenient.

I would start with a narrow outcome definition. A failed handoff occurs when a task reaches its agreed transfer point but the receiving coordinator has not acknowledged responsibility within one working day. We should confirm that definition with the customer rather than assume that every late update represents a missed handoff. I propose following forty active installation jobs across two regional teams for six weeks. We will compare the failure rate with a two-week baseline collected before the workspace is introduced. The comparison will not prove causation by itself, because job complexity and staffing may change. We can still make it useful by recording those factors and reporting the limitations alongside the results.

That definition is a good beginning, but some jobs remain with the same coordinator for the entire period. Counting forty jobs could make the sample sound larger than the number of actual handoffs. I suggest measuring eligible handoff events and reporting how many jobs generated them. We should also distinguish an acknowledgement from a meaningful acceptance. A coordinator may click a button without having the information needed to proceed. Could we add a completeness check covering the installation date, site contact, and outstanding dependency? Making them explicit would help us evaluate whether the receiving person can act, rather than whether someone has learned to keep the dashboard green.

Yes, we can define a complete handoff as timely acknowledgement plus those three required items. I will report incomplete and unacknowledged events separately, because their causes may differ. We should also record reopened handoffs where the receiving person sends the work back for missing information. Otherwise, people could appear successful by accepting everything and resolving the confusion later outside the system. For privacy, we only need job identifiers, timestamps, role labels, and the required field status. We do not need personal performance rankings or the contents of customer conversations. The shared report should evaluate the process, not create a league table of individual employees that neither company was asked to produce.

I support the process focus. The proposal should state that the customer decides which employees participate and remains responsible for its staffing decisions. Beacon will facilitate the working rules, while Aster will configure the supporting workflow. We should ask the customer to nominate one sponsor and two process owners who can resolve conflicting regional practices. If each region gives us a different instruction and nobody has authority to choose, the joint team will become an unpaid arbitration service. I also want the baseline collection included in the pilot plan rather than treated as a customer's homework assignment. Joon can guide it, and Sanjay can define the template, so we are responsible for making the evidence collection practical.

Let us address the phrase customer ownership. Neither company owns the customer, but we do need clear stewardship of the relationship. My proposal is that Beacon remains the lead relationship contact for this pilot, while Aster has direct delivery access within the agreed scope. Commercial proposals about the combined service will be discussed jointly. If the customer independently asks either company about unrelated work, that company should notify the other that a separate conversation exists, without sharing confidential details the customer has not authorized. I would resist an absolute ban on future contact, because the customer should retain freedom to choose its suppliers.

I agree that customer choice matters, but a notification rule alone may not protect Beacon's investment. We will introduce your team to operational contacts we developed over years. If those introductions become a route to selling around us during the pilot, we will have taken the relationship risk without a durable role. Could we agree that neither company will use pilot contact lists for unrelated outreach during the pilot or the following sixty days? A customer-initiated inquiry would be different and could proceed with the notification you described. I am asking for a limited boundary around information shared for this particular collaboration.

That is workable for Delivery. We will use the contact list to configure, support, and evaluate the pilot, not pass it to a general prospecting campaign. I want the rule to distinguish a support follow-up from solicitation, though. If a user reports an issue, our engineer must be able to contact them directly without waiting for approval from both relationship teams. We can record the interaction in a shared issue log and copy Joon on changes affecting the working rules. For purely technical troubleshooting, a summary is enough. Transparency should make the work visible, not turn each routine exchange into a committee meeting.

I support that distinction. We should give the customer one contact map showing who handles technical issues, process questions, and commercial decisions. Beacon will coordinate the overall check-in, but users can reach Aster's support route directly. If a question crosses the boundary, the receiving team will bring in the other company rather than tell the customer to start again elsewhere. I would also like a no-surprises rule for customer messages. Before either company announces a material change to the pilot, both leads should review the message. Routine support can move quickly, while changes to timing, scope, or the proposed next step need a joint explanation that does not make the customer reconcile two different stories.

Beacon can commit eighty advisory hours across preparation, workshops, weekly check-ins, and the closing review. I propose that Aster commits a comparable named delivery capacity rather than saying support is available whenever needed. We should state which work each company absorbs and which customer requests would require a separate decision. I also want to challenge the proposed success threshold of a thirty percent reduction in failed handoffs. If the baseline failure rate is already low, that threshold could be meaningless or depend on only one event. We need a minimum evidence volume and a qualitative check that the process is actually easier for the customer, not simply more carefully measured.

I agree. We should require at least sixty eligible handoff events during the live period before interpreting the reduction threshold. If the volume is lower, the result will be inconclusive rather than automatically unsuccessful. For a continuation recommendation, I suggest three conditions: a thirty percent relative reduction in the complete-handoff failure rate, no critical operational disruption caused by the pilot, and confirmation from both customer process owners that the working rules are sustainable. We will also show the absolute rates and event counts. A movement from ten failures to seven is different from a movement from one failure to zero, even if both look attractive as percentages. The report should make that difference obvious.

Aster will commit ninety delivery hours, with me responsible for configuration and Sanjay responsible for the evidence model. I am comfortable with the success conditions, provided we define a critical disruption before the pilot starts. For example, a platform problem that prevents a scheduled installation team from receiving its required work information would qualify. A temporary reporting delay that does not affect the operation would not be the same severity. We should also separate customer process changes from platform defects in the issue log. It is about choosing the right remedy when a problem appears. More software configuration will not fix an unclear handoff rule, and another coaching session will not fix a broken notification.

We will price the combined pilot at eighteen thousand dollars, with ten thousand allocated to Aster and eight thousand to Beacon. Beacon will send the customer one consolidated invoice, and the intercompany settlement will follow the recorded allocation. Before confirming the price, each company must verify that its committed hours and expenses fit the amount. We should not quietly subsidize extra work and then use the resulting exhaustion as evidence that the partnership cannot scale. Any request beyond the named deliverables will be assessed jointly, with the customer's outcome and the effect on effort both made visible.

We need to make the end of the pilot as clear as its beginning. The customer should not discover on the final Friday that its task history will disappear on Monday. I propose a read-only transition period of fourteen days after the live pilot ends, with an export of the agreed job records and working rules. Beacon can lead the customer handover, while Aster provides the export and explains its structure. If the customer does not continue, its existing process must remain available throughout the pilot so it has a practical destination. We should not create dependency and then describe the subscription as optional when leaving would require the customer to reconstruct six weeks of work from memory.

I can provide that transition period. We will test the export before the live pilot, using sample jobs, so the handover is not an unverified promise. The customer will confirm that it can read the fields and use the records in its fallback process. For early termination, I suggest three triggers: a critical disruption that cannot be contained, withdrawal of the customer's sponsor, or a material breach of the agreed data handling rules. Either company can recommend a pause, but the customer sponsor must be informed immediately. While paused, the workspace can remain read only if that is safe. We should not continue processing simply because the planned end date has not arrived.

I would add a partnership-level condition. If one company repeatedly fails to provide its named capacity and the other must cover the gap, we should have a correction window rather than silently continue. The leads can agree a five-working-day recovery plan with specific actions. If it fails, we jointly propose ending or reducing the pilot, with the customer choosing between the practical options. That protects the customer from our internal disagreement. I would not make an ordinary disagreement about a report an automatic termination trigger. The exit clause should respond to persistent inability to deliver, not give either side a convenient escape whenever collaboration becomes uncomfortable.

For data closure, Aster will retain the operational dataset only through the transition period and then remove it from the pilot workspace, with deletion recorded. Beacon will return or remove its copies of customer job records on the same schedule. We can retain an aggregated learning summary only if the customer approves it and it cannot identify their organization or individual staff. Neither company should use the customer name, logo, or a performance claim in publicity without a separate written approval. We should also agree that internal partnership lessons can describe process issues without reproducing confidential customer details in a wider presentation.

Let me put dates against the work. Elise and I will finalize the joint offer by Wednesday, October fourteenth, at three p.m. Asia/Seoul. Joon will confirm the sponsor, the process owners, and the participating teams by Thursday, October fifteenth. Dev and Sanjay will demonstrate the workspace, baseline template, and export by Friday, October sixteenth. We propose collecting the baseline from October nineteenth through October thirtieth, then running the six-week live pilot from November second through December thirteenth. The read-only transition will run through December twenty-seventh. Those are proposed dates until the customer accepts them. No team should invite users or request production records before the customer has confirmed the plan and the contact boundaries.

I will confirm those dates with the customer and bring any staffing conflict back to both leads. I will also prepare a one-page responsibility map showing the sponsor, process owners, support routes, and escalation contacts. During the live pilot, Beacon will chair a weekly operational check-in, and Aster will bring the issue status and evidence summary. The customer should leave each check-in knowing what changed, what needs their decision, and what will happen before the next session. I will keep the discussion focused on the handoff problem rather than allow it to become a general consulting session covering every frustration the regional teams have.

Our next agreement review is Monday, October nineteenth, at two p.m. Asia/Seoul, for forty-five minutes. We will check the customer confirmation, responsibility map, tested export, and baseline readiness before the collection period begins. I am comfortable with Beacon leading the relationship while Aster has direct delivery access under the contact protocol. The limited outreach restriction and customer-initiated exception address my main concern without treating the customer as an asset we can divide between companies. I will brief our advisers on that distinction. They should not obstruct technical conversations to protect the relationship, and your team should not interpret delivery access as permission to begin unrelated prospecting during the agreed restricted period.

That captures the balance we needed. We have a shared operational objective, named capacity from both companies, customer-controlled participation, measurable continuation conditions, and an exit that preserves the customer's ability to work. I will send the decision record today and ask each owner to confirm the actions assigned to them. Please flag any wording that promises more than the teams can deliver or makes the customer's choices narrower than we agreed. At the next review, we need evidence that the offer is workable, including the export and contact map, rather than enthusiasm about the partnership alone.