Instruction prerequisites tell customers whether they can begin a task and what they need to complete it. Without them, someone with the wrong role or missing materials discovers the obstacle only after visiting several screens. A short “Before you begin” section prevents these attempts when every condition can be checked and has a useful alternative. In a knowledge base and FAQ, place it near the beginning of the specific instruction, before the numbered actions start.
Select conditions that genuinely block the task
A prerequisite is a circumstance without which the customer cannot perform the task or will obtain a different result. A role allowed to invite teammates qualifies, whereas “familiarise yourself with the entire dashboard” usually does not. For the chosen task, walk through the process with an account representing the reader and note where specific access, an existing object or a prepared material is required. Move only those confirmed requirements ahead of the first action in the article.
Do not turn the opening into a list of every product setting or possible contractual restriction. Readers need information for this one action, and excessive warnings make the real obstacle harder to find. If the feature depends on a plan, check the current application permissions and describe how to recognise availability instead of inserting a price or promising access for every account. Help for trial users can link to support during a SaaS trial while still checking the requirement relevant to this particular task.
Replace “you must” with a way to check
A verifiable condition names the required state and tells customers where they can recognise it. “You must have the appropriate permissions” leaves readers wondering what “appropriate” means. A better formulation is: “Invitations are sent by someone with the role shown in team settings; check your own role in the location available to your account”. Match the role name and location to the actual interface rather than copying a familiar label from a different product.
For materials, state what to prepare and where to obtain a missing item. Confirm the invited person’s address with its recipient instead of guessing from old correspondence. For an import, a list of required columns is more useful than “prepare a valid file”, provided the format has actually been checked. Plain language in customer support helps remove vague expressions, but clear wording still needs evidence showing that a condition has been met.
Offer a practical alternative when a condition is missing
The alternative should name an action available to the person who has just discovered a restriction. Someone unable to invite a teammate may pass the address and required access scope to an authorised administrator. Someone missing a material should know where to obtain it or how to postpone the task without losing existing work. The table describes an illustrative application; it does not define Meetlead team roles, capacity limits or invitation requirements.
Scroll the table sideways to see all columns.
| Condition | How to check it | What to do if it is missing |
|---|---|---|
| A role allowed to invite people | Access to the relevant team settings | Ask an authorised person to send the invitation |
| The recipient’s correct address | Confirmation with the recipient | Establish the address before sending |
| An available place under account settings | Capacity shown in the application | Review the options with the account administrator |
Do not tell everyone to “contact support” when the only person needed is the account owner or the holder of a missing document. Name the appropriate recipient and the minimum information they need to decide what happens next. Do not encourage password sharing, using another person’s session or bypassing role restrictions. If an alternative feature produces a different result, explain that difference so customers do not confuse a workaround with full completion of the original task.
Write a complete “Before you begin” block
An illustrative block could say: “Before sending an invitation, check that your role allows you to invite people to this team. Prepare the recipient’s confirmed address and agree on the access they should receive. Also check the available capacity shown in account settings. If you cannot manage the team, pass this information to someone who has that permission.” These four sentences cover access, material, account state and an alternative route that the reader can actually follow.
Below the block, add a sentence marking the start of the instruction: “Once these conditions are met, open the team section and select the option to add a person”. Do not repeat the whole opening at every step, but mention a condition again when the process changes access scope or the object being edited. Adapt the entire example to your own application. A title should announce the task, as explained in help article titles, so the right person finds this information before starting.
Google’s guidance on writing procedures discusses context and information needed to complete a task. The condition–check–alternative structure is the editorial approach proposed in this article.
Distinguish a missing prerequisite from an error
A missing prerequisite means the task should not start yet, while an error occurs during an attempted action. Do not call an unavailable button a fault if it is the expected result of having no selected object. Equally, do not explain every failure through the user’s role when the conditions were met and another message appeared. The instruction should help people distinguish these situations without blaming the customer for a restriction or hiding a genuine malfunction.
If the process still fails after conditions have been confirmed, link to troubleshooting instructions for the specific symptom. Carry forward the information about conditions already checked so the reader does not restart the investigation in the second article. Avoid filling “Before you begin” with the entire error tree. Prerequisites and troubleshooting serve different moments, even when they concern the same action and deserve a clear link between their respective instructions.
Check the opening with readers in different roles
A walkthrough with two roles shows whether the conditions also help someone without full access. One person should begin after checking the requirements; the other should find the right alternative without entering unavailable screens. Note whether both can recognise their state and identify the next route. Do not consider the presence of a prerequisites section a success if its wording still requires a team member to explain what it means in practice.
Explore Meetlead MeetAI and the knowledge base to check how you can provide help in your environment with the required permissions. Update the opening when a role name, setting location or required material changes; accurate later steps cannot compensate for an incorrect starting point. Review links to alternatives with the owner of the task as well. If they lead to a screen unavailable to the reader, replace them with information that person can actually use.
Questions about instruction prerequisites
Does every instruction need a separate prerequisites section? No, not when the task has no significant requirements beyond those already evident from its context.
A short condition can sit in the introductory sentence instead of creating an empty block. A separate section helps when readers must check access, prepare materials or choose an alternative. Its length should follow the task rather than the publication template.
Is naming the required plan enough? Not always, because a plan does not establish the user’s role or the state of the particular task. Also explain how to recognise feature availability on the account and what someone unable to manage the plan can do.
Verify plan names and conditions before publishing. Do not suggest a purchase or organisation-wide settings change to someone who is not authorised to make that decision.
