01What this guide helps you do
Submit a clear request under the existing Communications policy.
This guide focuses on one task within plans & billing. Its completion test is specific: Support receives a complete request that can be reviewed. Use that result to decide whether the task is finished. Opening a page, entering a value or seeing a brief notification can be part of the process without establishing the complete result.
02When to use this workflow
Use this workflow when your immediate goal is to request a refund within the published window. Keep the scope limited to the relevant billing record. If you are solving a different problem, use the related guides at the end rather than applying every action here to unrelated records.
The usual operational owner is the workspace owner or billing contact. If another person owns the relevant business facts or permissions, involve that person before changing the shared record. Individual access and business authority are not always the same thing.
03Prepare the information you need
Identify the edition, seller, subscription term and intended workspace before starting payment. The published India plans are ₹999 monthly or ₹9,999 annually; UK plans are £9.99 monthly or £99 annually. Read the current order summary because it governs the actual purchase. Keep platform access, provider messaging and separately purchased usage distinct when estimating the total cost of operating the service.
Payment date, account email, workspace, payment reference.
04Find the right workspace and feature
Start from Settings → Plans & subscription and Billing & invoices. Treat this as a feature locator: the arrangement of menus can differ between the web interface and the native application. Confirm the workspace name and the relevant record before proceeding, especially if you manage more than one business or use both India and UK accounts.
The target of this task is a billing record. Keep its identity visible while you work. A similarly named record or a previously open browser tab can otherwise make a correct action affect the wrong context.
05Understand the information on screen
| Information | What it means | Practical check |
|---|---|---|
| Edition and seller | Commercial context of the purchase | Match checkout and terms |
| Term | Monthly or annual period | Review before payment |
| Payment reference | Safe reconciliation identifier | Keep with the receipt |
| Usage charges | Provider and additional consumption | Do not assume unlimited inclusion |
Apply these distinctions to the specific inputs for this guide: payment date, account email, workspace, payment reference. You do not need to collect every possible field in the workspace. Use the information needed to make this decision and to verify its result.
06Inspect the current state first
Review the current subscription status, paid period and checkout details. Current self-service plans renew manually, so do not describe them as an automatic recurring debit unless the actual order says otherwise. The standard trial is seven days, but use the account's displayed state for its remaining time. Tax treatment should be read from the current offer, final summary and resulting invoice rather than guessed from a currency conversion.
If the intended result is already present, check whether any further action is necessary. This is particularly useful after an interrupted session or when another teammate may have completed part of the work.
07Step 1: Check the seven-day request window
Begin with the relevant inputs: payment date, account email, workspace, payment reference. Resolve any ambiguity that would change which record or business decision the task concerns. Keep a short note of the original state if you will need to compare it later. This creates a clear starting point for the next action instead of relying on memory after several screens have changed.
08Step 2: Prepare the identifying payment details
Use the result of the first action as the context for this one. Check the exact label, selected value or evidence involved rather than assuming that a default matches the intended task. If you identify an inconsistency, resolve it before proceeding. Keep the change narrow enough that its effect can be understood without comparing many unrelated edits.
09Step 3: Send the request to public support
Finish by checking the observable result, not only whether the interface accepted an interaction. If the result is still pending or cannot be verified, preserve that distinction in your notes. A clearly recorded unresolved state is more useful than announcing completion and discovering the missing part during a live customer task. Use the verification guidance below for the relevant feature.
10Submit a complete request without overstating the policy
The published voluntary process allows refund requests within seven calendar days of payment. Include the account email, workspace name and payment reference so support can locate the purchase. Explain the request clearly and avoid sending full card details or an unredacted bank statement.
Incurred Meta and other third-party usage charges are excluded under the stated policy, subject to applicable mandatory rights. A request being within the window is not a statement that every category of charge is automatically refunded. The policy also does not remove statutory rights that may apply to the particular purchase.
| Check | Meaning for this task |
|---|---|
| Request identifiers | Account, workspace and payment reference |
| Usage distinction | Incurred third-party consumption is separate |
| Applicable rights | Mandatory protections remain preserved |
11Worked example
An owner submits a request with the payment reference rather than only a screenshot of the dashboard.
The useful lesson is the sequence of decisions, not a promised result for every business. In this scenario, begin with “Check the seven-day request window”, continue with “Prepare the identifying payment details”, and finish with “Send the request to public support”. Compare the result with the completion test before applying the same process to a wider set of records.
Use invented names and references when practising this example. Keep the structure realistic, but do not copy a live customer conversation or payment record into training material simply to make the demonstration look authentic.
12Verify the result
After payment, keep the provider receipt and check the workspace subscription state. Match the account and payment reference before concluding that access did not update. For a commercial question, use the seller and terms for the selected edition. The India seller is Alactic Enterprises Private Limited; the UK edition is sold by Alactic Inc, a United States company, with Stripe checkout when available.
Support receives a complete request that can be reviewed.
13Decide what to do next
| What you observe | Appropriate next step | What to avoid |
|---|---|---|
| The expected result is visibly present. | Keep the result and continue with the intended business task. | Repeating a completed action without a reason. |
| The result is still pending or uncertain. | Review the current billing record and the relevant status. | Calling the task complete without evidence. |
| The result conflicts with the intended choice. | Revisit: Prepare the identifying payment details. | Changing unrelated records to hide the symptom. |
Use the observed state to choose a branch. A recovery action should address the actual cause and preserve any work that is already correct. If several people are involved, make the next owner explicit so a pending state does not become an unattended task.
14The main mistake to avoid
A request window is not a guarantee of an automatic full refund in every case.
This mistake can make the task appear finished while leaving the business outcome unresolved. Return to the inputs and the named steps when the result is unclear. Keep a useful distinction between what you observed and what you expected. If a weaker signal is all that is available, describe the remaining uncertainty and identify how it can be checked.
15Diagnose an unexpected result
Compare the expected result with the exact current state of the billing record. Record which of the three actions was last completed and what happened next. Keep the exact validation message or visible status where one exists. This separates an input problem from a saved-state problem and helps another person reproduce the same example.
Check the workspace, selected record and current view. Change one relevant factor at a time. If you change several unrelated settings together, a later success may not explain which change actually resolved the issue.
16Recover without duplicating work
If a return page is delayed, check whether payment completed before trying again. For a refund request, provide the account email, workspace, payment date and reference through public support. The published voluntary policy permits requests within seven days of payment and excludes incurred Meta or third-party usage, subject to mandatory rights. It is a request process, not an unconditional promise of every possible refund.
If the result depends on a provider or another authorised person, record that dependency and use the appropriate route. Do not simulate success by manually changing an unrelated display value or by removing evidence of the original outcome.
17Use the workflow on web and mobile
Small checkout screens can make the subscription term easy to overlook. Review the selected monthly or annual option and the final amount after closing the keyboard. Keep payment credentials inside the authorised payment flow; support normally needs a transaction reference rather than full card or banking details. If switching devices after checkout, verify the same workspace before comparing subscription state.
When comparing devices, match the same account, record and relevant filters. A desktop screenshot and a mobile screen from different contexts are not evidence of inconsistent data. If a layout problem prevents completing the task, report the screen name, device context and the affected control with private details removed.
18Keep a useful operational record
Retain only the information needed to explain the task: its purpose, the relevant billing record, the action taken and the observed result. If the operation produced a safe reference, keep it with the time and workspace context. This makes a later handover or support query more precise than a screenshot with no explanation.
| Record | Useful content |
|---|---|
| Purpose | Submit a clear request under the existing Communications policy. |
| Inputs reviewed | Payment date, account email, workspace, payment reference |
| Outcome to verify | Support receives a complete request that can be reviewed. |
| Next owner | Workspace owner or billing contact |
19Protect private information
Use the minimum customer or business information needed for the task. Restrict access to authorised colleagues, and redact unrelated names, numbers and message content when sharing a screenshot. An evidence reference is often more suitable than copying the underlying private document into a general field or support message.
For this workflow, the useful input categories are payment date, account email, workspace, payment reference. They should help you make and verify the decision; they are not a reason to publish a customer database, credentials or internal operating notes. The fictional example in this guide can be used for training without exposing live records.
20Know the limits of this workflow
The order, invoice and current Communications terms govern the purchase. Estimates do not guarantee a provider bill or unlimited usage.
Separate the workspace subscription from Meta messaging and separately purchased usage. Check the seller, currency and paid period before approving payment.
Read the linked source material for decisions controlled by a provider or by the applicable commercial terms. A practical guide explains how to approach the task; it does not add a new contractual guarantee or establish that every business use is legally suitable. Use the responsible business owner for unresolved exceptions.
21Review the process over time
Assign renewal responsibility and check expiry before important launches. Keep receipts in an authorised location and separate cancellation, renewal and data-deletion requests. The commercial refund window does not remove mandatory statutory rights; consumer questions may need a different legal analysis from ordinary business purchasing. Use current provider pricing for usage estimates and date the assumptions rather than copying an old rate card indefinitely.
Update related instructions when the underlying business fact or product behaviour changes. Keep a representative example from this workflow so a future revision can be compared with an explicit expectation rather than judged from memory.
22Practical questions
What should I check before starting?
Prepare payment date, account email, workspace, payment reference. Then confirm the workspace and the relevant billing record. The first action is “Check the seven-day request window”. Starting there keeps later decisions grounded in the correct record and avoids trying to solve a different problem with this workflow.
How do I know the task is complete?
Use this observable test: Support receives a complete request that can be reviewed. If a state is pending, describe it as pending. If a save or provider operation is uncertain, inspect the current record before repeating it. The result matters more than whether a button was pressed.
What if the result still does not match?
Review this risk first: A request window is not a guarantee of an automatic full refund in every case. Keep the exact symptom, the relevant reference and the last completed action. Ask the workspace owner or billing contact or the appropriate support route to review the remaining issue, using a small reproducible example rather than a broad export of customer data.
23Completion checklist
Use this checklist as a final review of the task, not as a substitute for the steps above. If an item remains unresolved, identify the next action and its owner. Do not mark a provider-dependent or unverified result complete merely because the rest of the checklist is finished.
- The intended workspace and billing record were identified.
- The necessary inputs were reviewed: payment date, account email, workspace, payment reference.
- Check the seven-day request window.
- Prepare the identifying payment details.
- Send the request to public support.
- The result was checked: Support receives a complete request that can be reviewed.
- The task-specific risk was considered: A request window is not a guarantee of an automatic full refund in every case.
- Any unresolved issue has an accountable next owner and a useful evidence reference.