Your China Partner Should Own a Queue, Not Just a Contact List.

A publisher’s contact list may create opportunities. The relationship becomes operational when both sides share a prioritised queue with named people, deliverables, dates, dependencies, acceptance tests, and escalation. If introductions, chat messages, and optimistic calls carry most of the work, the first missed build or player incident will expose the missing structure.

Contract, publishing, data, and operating arrangements need review for the actual parties and route. The method here is an accountability tool, not a model agreement.

Convert every capability claim into a delivery card

Partner decks use broad nouns: publishing, approval, localization, marketing, channels, community, operations, support. Each noun can hide dozens of tasks.

Take “store operation.” Does it include account creation, entity verification, product-page copy, art adaptation, package upload, review replies, pricing, discounts, release controls, patch notes, refunds, data export, and page closure? Which storefront? Which tasks require studio approval? Which tasks belong to another vendor?

For every claimed service, create a delivery card with:

• Outcome: the player or business result this work enables.
• Owner: one accountable person on the partner side and one on the studio side.
• Artifact: a file, configured account, submitted package, live page, report, tested build, support log, or decision record.
• Acceptance: observable conditions that make the artifact usable.
• Due date: a date or explicit dependency.
• Inputs: what the owner needs and from whom.
• Evidence: link, export, screenshot, receipt, version, or test result.
• Escalation: who decides when blocked and by when.

A post becomes a deliverable when it links back to a campaign brief, approved asset set, date, tracked URL, spend record, result report, and learning decision.

Keep one shared view across different tools

The partner may use an enterprise system while the studio lives in a lightweight tracker. Do not force a tool migration unless it solves a real access problem. Agree on one shared view containing the fields above. It can be synchronized manually at a fixed cadence.

Group work by stream:

• rights and contracting;
• content and approval preparation;
• localization and linguistic QA;
• build and platform delivery;
• storefront and channel operations;
• infrastructure, SDKs, identity, data, and security;
• marketing and creators;
• community, moderation, and support;
• launch, incidents, reporting, and finance;
• updates, renewal, shutdown, and exit.

Review blocked items first. A red rights document can stop ten green marketing tasks, while a missing test account can invalidate a reported build milestone. Let dependencies set queue priority instead of department volume.

Ask for artifacts another teammate can verify

A teammate who missed the call should still be able to check the artifact.

For localization, ask for source and target files, termbase, style guide, query log, build screenshots, linguistic-QA report, and resolved defects. For approval work, ask for the current material list, versioned submission package, qualified content feedback, correction log, and formal status evidence the partner is permitted to share. For marketing, ask for the audience hypothesis, channel plan, creator criteria, asset calendar, URLs, budget, report, and next action.

For support, ask for queue access or a meaningful export, category and severity rules, response templates, escalation records, and a recurring issue digest. A monthly slide saying sentiment was positive cannot help an engineer reproduce a crash.

Do not demand sensitive documents without a lawful and necessary reason. The goal is appropriate evidence and visibility, not surveillance. Agree in advance what each party can share, in what form, and with which access controls.

Make account ownership boring

Account disputes become dramatic because teams postpone boring questions.

List every developer, storefront, social, advertising, analytics, localization, server, support, moderation, payment, and reporting account. Record the legal owner, day-to-day administrator, recovery method, permissions, billing owner, data export method, and what happens at exit.

Use role-based access where available rather than shared passwords. Keep recovery routes controlled by the proper entity, with more than one authorised person. Test access before launch. A contractual right to data is not useful if the studio has never seen the dashboard and the only operator is on holiday.

The account schedule should match the commercial arrangement. If a local operator must hold a particular account, document how the studio receives reports and approves material decisions. Do not solve a route requirement by pretending the studio owns something it cannot lawfully or practically control.

Specify reports before launch produces data

“You will receive reports” is too weak. Specify:

• fields and dimensions available;
• raw, aggregated, or sampled level;
• reporting delay and timezone;
• currency, tax, refund, chargeback, and revenue-share treatment;
• acquisition attribution limits;
• player-data access and lawful-purpose restrictions;
• export format and delivery cadence;
• correction process when numbers disagree;
• access after termination.

Product and commercial reports answer different questions. The studio may need to know whether players understand onboarding without receiving identity data it does not need. Design the report around decisions, then minimise the data.

Run a sample before launch. Ask the partner to populate a dummy or historical template so both sides discover ambiguous definitions early.

Keep material decisions in one shared log

Create a decision log for price, discounts, product naming, content changes, localization terminology, store claims, creator commitments, launch date, build release, rollback, public incident messages, and shutdown. Each entry should record the decision, date, owner, evidence, affected artifacts, and review condition.

This protects speed. During an incident, the team should not search weeks of chat to learn who can pull a build. During a localization dispute, it should know whether a term is a stylistic preference, platform constraint, or reviewed content requirement.

Decision rights belong in the agreement and the working process. If the contract says the studio approves price but the only storefront operator takes instructions from someone else, the paper and operation disagree.

Put response times on the escalation path

A list of names becomes an escalation path only after each level has a response expectation and decision authority.

Set severity levels with examples. A critical issue might include inability to launch, widespread login or entitlement failure, serious security or data concern, or a required service failing for a large player group. A high issue might include a major localization defect, broken purchase path on one channel, or a rapidly growing support problem with a workaround.

For each severity, define acknowledgment target, decision owner, update rhythm, and authority to roll back, disable a feature, change messaging, or stop release. Use targets the teams can staff. There is no value in writing a fifteen-minute response promise if nobody is on duty.

Practice with a tabletop exercise. Walk through a bad build, a verification outage, a price error, and a sensitive mistranslation. Note every missing credential, unclear owner, and slow approval. Update the queue while the finding is fresh.

Plan the exit while goodwill is high

Every agreement ends: expiry, success, acquisition, strategic change, poor performance, or dispute. A responsible exit protects players and both teams.

Cover:

• notice and cure periods;
• account and page transition where permitted;
• final builds, localized source, termbase, art, trailers, and submission materials;
• support and community messages;
• refunds, outstanding payments, and final reports;
• data return, retention, deletion, and lawful continuing duties;
• live service, domain, server, and SDK shutdown or transfer;
• player access and save continuity where feasible;
• rights to continue international-storefront Chinese support outside the arrangement.

Do not assume an approval, account, or operator relationship can simply be transferred. Ask qualified advisers and platforms what is actually possible. The contract should not promise a technical or regulatory action neither side controls.

Run a weekly review around blockers and evidence

Run a short operational review with the shared queue on screen:

1. blockers that threaten the route or critical path;
2. artifacts due before the next review;
3. decisions needed, with owner and deadline;
4. new risks in product, approval, platform, data, community, or schedule;
5. evidence from players and operations;
6. changes to assumptions, scope, or stop conditions.

Finish by reading back commitments. Update the queue during the meeting, not later from memory.

Contacts can introduce creators, platforms, service providers, and decision-makers. The queue shows whether those introductions become work the team can ship. Prefer the partner whose delivery machinery becomes clearer under scrutiny over the one whose promise keeps expanding.