{"id":361,"date":"2026-09-16T07:30:00","date_gmt":"2026-09-15T23:30:00","guid":{"rendered":"https:\/\/oribridge.org\/blog\/?p=361"},"modified":"2026-09-08T09:37:37","modified_gmt":"2026-09-08T01:37:37","slug":"course-build-not-unlimited-support","status":"publish","type":"post","link":"https:\/\/oribridge.org\/blog\/course-build-not-unlimited-support\/","title":{"rendered":"A Course Build Is Not an Unlimited Support Commitment"},"content":{"rendered":"

\u201cWe\u2019ll help after launch\u201d sounds generous in an overseas course proposal. It also sounds harmless until the client asks for a platform fix, a new lesson, weekly office hours, learner replies and a report three months later.<\/p>\n

Chinese course-construction documents make the hidden expansion visible. A Zhaoqing University smart-course production project lists resource support, platform maintenance, consultation, user training and after-sales work. A Southwestern University of Finance and Economics online-course construction procurement describes a running course, promotion, Q&A or assistant work and technical response. These are specified project scopes, not universal contract rules. They are useful because they show how many different jobs can sit beside \u201ccourse production.\u201d<\/p>\n

The commercial decision is simple: define support as a bounded scope before the build begins.<\/p>\n

The phrase \u201ccourse build\u201d is doing too much<\/h2>\n

A course build can include content design, recording, editing, translation, platform setup, testing and handoff. It may not include ongoing maintenance, learner support, platform operations or promotion. If those are included, they should be named as separate work.<\/p>\n

The Zhaoqing project\u2019s published scope is a good reminder that maintenance, consultation, training and after-sales are not the same action. The Southwestern University document similarly places course operation, promotion, Q&A or assistant support and technical response beside the course itself.<\/p>\n

The sources do not say that every buyer needs all these services. They do not establish a support period, response time, price or qualification for an overseas expert. They show only that a specified project may distinguish them.<\/p>\n

Four lanes for a clear offer<\/h2>\n

Build<\/h3>\n

What is created? Curriculum, scripts, videos, exercises, translated assets, course pages or a content package? Define the accepted artifacts. \u201cA complete course\u201d is not an artifact until the number, format and review point are clear.<\/p>\n

Launch and handoff<\/h3>\n

Who uploads, configures, tests and accepts the course? Is the handoff a file transfer, an operating platform, a live orientation or a signed internal receipt? A launch can be part of a build or a separate phase; the offer should state which.<\/p>\n

Limited support<\/h3>\n

If support is included, define its boundary: a fixed number of review sessions, a stated support window, a named channel, or correction of specified defects. Avoid importing legal or SLA language unless the responsible contract process has approved it. This article is a scope-writing method, not contract advice.<\/p>\n

Excluded ongoing operations<\/h3>\n

List what is not included: new modules, content updates, continuous moderation, learner counselling, platform administration, promotion, new integrations, analytics reports or emergency response. Exclusions are not an apology. They protect the reader from interpreting \u201csupport\u201d as unlimited availability.<\/p>\n

A scene: the one-time build that became a team<\/h2>\n

An expert quotes a six-week course build. The client supplies a platform and asks for \u201ca little help after launch.\u201d During week eight, learners report confusing instructions. The client asks the expert to rewrite two lessons, answer questions every Friday, check the platform and provide a monthly performance report.<\/p>\n

None of those requests is unreasonable in isolation. Together they are a new operating service. The original offer did not say who owned the platform, how long support lasted or which artifacts were included. The ambiguity is now being settled by urgency rather than by a clear decision.<\/p>\n

The scenario is a constructed example, not a customer case. Its purpose is to show why the support boundary belongs in the initial scope.<\/p>\n

What the sources can and cannot do for pricing<\/h2>\n

A public course project can reveal that maintenance, consultation, training, technical response or promotion were listed as project work. It cannot establish a normal price for those services. A total project amount, where published, is not a per-lesson, per-hour or per-support benchmark.<\/p>\n

Do not copy a university\u2019s support language into a sales page as if it were a market standard. Do not infer that a foreign expert can offer the same technical service. Use the source to ask: \u201cWhich work did this specified buyer choose to name?\u201d Then design the smallest scope your own delivery can honestly support.<\/p>\n

The support window is not a guarantee of outcome<\/h2>\n

A bounded support period can clarify availability. It cannot guarantee that learners will finish, that the platform will remain unchanged, or that the course will produce a business result. If the client wants a measured learning or operational result, define a separate test and evidence path.<\/p>\n

For example, \u201ctwo review calls during the first 30 days\u201d is a support scope. \u201cThe course will become effective within 30 days\u201d is an outcome claim. The first describes a service activity; the second needs evidence and careful definition.<\/p>\n

A counterexample: when no support is correct<\/h2>\n

If a client already has a platform team, editor and learner-support channel, a content-only handoff may be the best fit. The course build can end at approved files and a transfer note. Adding a support retainer would create work the buyer does not need.<\/p>\n

Similarly, a one-hour expert talk may have one completion point and no course operations. Do not force a full support matrix onto a narrow engagement.<\/p>\n

The five questions before accepting the build<\/h2>\n