MKT.9:4 - Solution
MKT.9:4.1 - Name the decision and the differences that can change it
Recover the useful result, the person or group receiving it and the immediate decision. Distinguish selecting an offer, selecting help for an acquired service and constructing a new service. The relevant information differs: a purchaser’s spending limit may matter to the first decision, while access and present ability may determine the second.
Ask what difference would change the suitable action. Start with the required use, available time, access, necessary ability, support, material constraints and preferences that affect the result. For each proposed attribute, explain which alternative it can select or exclude. Omit an attribute whose value cannot change the decision. A broad market group can provide a useful starting hypothesis through MKT.1; it does not settle the individual’s conditions.
When the result itself is unclear, use MKT.6 to obtain an agreed contribution before choosing its variant. When sufficient conditions are already known, proceed without asking the customer to repeat them.
MKT.9:4.2 - Qualify the information used for this choice
Recover the source, subject and currentness of the information. Distinguish something the customer stated from an inferred preference, a recorded action or an assumption supplied by a model. Confirm an action-changing condition when the present decision cannot safely rely on its existing basis. A person’s earlier attendance does not establish current availability; a click does not establish that they can perform the required work.
Use information under its applicable access and use conditions. Make consequential information correctable by the person or other appropriate source. An organisation’s purchaser, user and access authority can supply different answers; do not merge their preferences or permissions into one profile.
If a needed condition is unknown, choose the least elaborate adequate continuation: ask a focused question, offer a clearly conditional option, use an available suitable default, or stop the dependent selection. A default is suitable only when its consequences remain acceptable under the unresolved difference. More data collection is warranted when its answer can change the proposal enough to justify the burden.
MKT.9:4.3 - Compare the actually available variants
Recover the existing variants as complete contributions: what each supplies, the useful result it can support, required customer work, access and ability, timing, support, terms and available supply. MKT.2 supplies this offer content. Keep proposed variants separate from ones the provider can presently deliver.
First exclude a variant that fails a necessary condition. Then compare the remaining alternatives by the customer’s relevant reasons for preference and the full burden of obtaining the result. Distinguish a favourable feature from a prerequisite: extra guidance can be optional convenience for an experienced user and necessary support for someone unable to proceed alone.
Compare combinations as well as individual options when the proposal joins several contributions. Check that the output of one is suitable for the next, that the same person or resource is not promised to incompatible work, and that the combined arrangement preserves support and failure handling. A set of individually available services is not necessarily available as one simultaneous package.
Return a supported selection with its grounds and conditions, or identify the exact unmet condition. If a ready variant suffices, arrange its use. If none does, decide whether an altered time or narrower contribution is useful before requesting new construction.
MKT.9:4.4 - Obtain a missing service configuration when selection is insufficient
Give SYSE.8 the receiving activity, needed result, differences between customers, constraints and candidate provider contributions. Ask for a feasible offering and provider arrangement. Where several methods or allocations must be combined, use ME.6 to compare their actual relationships, simultaneous work and burdens.
For a reusable service, these suppliers must develop the following connected construction:
- Identify contributions that can be reused by their supplied results, required inputs and conditions. Do not divide the service solely by existing department names.
- Construct materially different combinations that can obtain the receiving result. Keep the current adequate arrangement where one exists. Explain necessary order, compatible outputs, shared resources and failure or return conditions.
- Obtain the needed subject methods, competent people, assignments, access and support. Distinguish work that can be scheduled in advance from new requests, and work that can be interrupted from work that must finish before another action starts.
- Return available variants with their conditions of promise and execution, or the precise contribution still missing. Test consequential compatibility in an ordinary use and a revealing variation before relying on an untried combination.
For recurring service construction, retain useful alternatives with the conditions that made them feasible, conditional or rejected. Retrieve relevant earlier configurations when developing another proposal, then recheck their fit and the reasons for the earlier decision. Use them to generate and refine options; a changed result or condition may require a configuration outside the stored set.
A service-module description states a reusable contribution’s supplied result, required work and conditions. Developing that contribution may involve systems, people and several methods; calling it a module does not settle their composition. A list of options becomes usable only when the needed contributions and combinations can actually be supplied.
Marketing supplies the customer question and chooses among supported proposals. Engineering constructs the arrangement; HCD obtains needed capability; organisation change establishes assignments and enabling conditions; Operations performs the actual service. MKT.11 aligns their promises and returns any limit that changes the offer. Writing a personalized explanation can express the resulting service but cannot create it.
MKT.9:4.5 - Present a usable choice and arrange the selected help
Explain why the proposal fits the stated situation, what it requires and which consequential conditions remain open. Give the customer a proportionate way to correct the grounds, choose another suitable option or decline. If a preference was inferred, present it as revisable rather than as a fact about the person.
Make the next action feasible through MKT.4 and the actual receiving operation. A promise of assisted use needs available assistance; a modified timetable needs a real place in that timetable. When help is selected during use, show the person how to obtain it and what can happen while waiting.
If software supports the selection, specify the operation it is meant to perform and the same result conditions. Check representative cases, an action-changing missing or wrong input, and an incompatible combination. The software may rank suitable variants, explain them or execute an authorized action; these are different functions with different failure consequences. A generated description should refer only to supported contributions. Obtain a competent decision when the system cannot resolve a necessary condition within its assigned authority.
MKT.9:4.6 - Learn whether the match worked and revise the affected part
Obtain evidence that answers the question that justified the personalization. A relevant reply can establish understanding or a preference; completed access can establish a feasible transition; successful use and later benefit require their own evidence. Distinguish the quality of the selected variant from the accuracy of the information and the actual performance of the service.
When a match fails, repair the affected connection. Correct mistaken data, change the selection rule, obtain missing support, alter the variant or reopen the useful result. Do not infer that a customer segment is wrong from one failed supply case. Use MKT.12 for a consequential unknown and MKT.10 for a claimed causal gain from personalization.
Return the selected contribution or unresolved need, the grounds and limits of the choice, and the actual next result. Reuse a sufficient shared variant; create another only when a consequential difference warrants the extra construction and maintenance.