What you will finish
You will have a private page distinguishing a request under review from an approved request, an order placed and goods received. It will not contact suppliers, create team permissions or approve a request merely because its fields are complete.
1. Gather these details
- Choose a simple need, such as two specific office supplies. State the reason, quantity and required date before entering a price or selecting a supplier.
- Identify who has approval authority outside the tool and what information they require. Maintaining the register must not automatically make the coordinator the decision-maker.
- Prepare a sourced estimate showing unit price, delivery and inclusions. Mark an unknown charge as awaiting confirmation rather than entering zero simply to complete the form.
- Use short department, project and request labels without sensitive employee details. The purpose is to track a need and decision, not create personnel profiles.
- Decide how to reference the approval, its date and limits, such as a maximum amount or specific quantity. A conditional approval needs its condition recorded explicitly.
2. Define how the project works
1. Describe the need before the purchase
For each request, record the problem or task requiring a purchase, followed by item, specification, quantity and required date. An existing usable item or an alternative might already solve the problem, which makes a reason field useful. Start with draft status until the information is ready, then move to awaiting decision. Creating a record is not an instruction to purchase; it only documents something for consideration, not an approved budget.
2. Show an understandable estimate and its limits
Multiply quantity by unit price and add confirmed delivery or other charges not already included, while exposing missing information. Record the estimate’s source and date because terms can change. If the current decision is whether the need is justified, avoid turning this step into a full supplier comparison; reference a separate comparison when relevant. The decision-maker needs to understand what will be bought, why, the amount requested and what remains uncertain.
3. Record the decision actually received
After communicating outside the tool, record approved, declined or more information needed with the decision-maker, date, short evidence reference and limits. Typing an approver’s name must not generate automatic approval. If quantity, specification or cost changes afterwards, preserve the earlier decision and return the request to review. This prevents a different or more expensive request appearing covered by an approval that referred to an earlier version.
4. Separate approval, ordering and receipt
When an actual purchase is placed, enter its supplier order reference and date. When it arrives, record quantity and condition received. Approval does not prove an order was sent, and an order does not prove delivery. If only part arrives, keep the remainder visible and resolve it before closing the request. Factual receipt and correction notes make the next action understandable without asking everyone to reconstruct the same purchase history.
3. Work through an example
| Stage | Information | Status |
|---|---|---|
| Need | Two items with a stated specification | Draft |
| Estimate | 2 × 250 + delivery 50 = 550 | Awaiting decision |
| Recorded approval | Maximum 550 for the stated specification | Approved |
| Quantity changed to three | 3 × 250 + 50 = 800 | Requires renewed review |
| Order and receipt | Record only after they occur | Not implied by approval |
Approval for 550 does not automatically become approval for 800. Preserve the earlier decision while showing that the changed request needs a new one.
4. Set up your account and start the build
- Use your account or register.Visit www.gammal.tech/join. New account activation takes 1–10 days. Use a National ID from a country whose citizenship you hold; the official account guide explains the limited exceptions for Egyptian citizens. Submit identity documents only through the official registration process.
- Activate the WhatsApp subscription.After approval, open my.gammal.tech and add EGP 200 to your wallet, or use sufficient existing funds. Activate the monthly WhatsApp subscription in your account and check that it is active. Funding the wallet alone does not activate it. This subscription covers light personal use; website creation is charged separately.
- Open the building conversation.Message +201033998844 and send the following command by itself, including the required square brackets. Wait for confirmation of build mode:
[mode: build][mode: web]is an alternative for the same mode; you only need one command. - Send the request in the next section.Replace its placeholders and ask for exactly one page using an available name of at least three characters. Before execution, request an itemised quote separating the one-time build fee, EGP 100 for the first month of standard hosting and any additional usage. Ask how changes beyond the agreed scope are charged.
- Check the total and approve the build.Once you understand the quote, return to your account and add any missing funds. Return to WhatsApp and confirm the scope and price. Some simple sites take minutes; requirements and revisions affect timing. Open the resulting address and run this guide’s acceptance checks.
- Record the renewal date.MeNooN hosting renews manually: select the duration and confirm payment before expiry. Leaving funds in your wallet does not renew it automatically. Send
[exit], including brackets, when you finish the building conversation.
Budget: quoted build fee + EGP 100 hosting + EGP 200 for one WhatsApp month if it is not already active, plus agreed usage. Twelve months of standard hosting cost EGP 1,200; adding one WhatsApp month makes EGP 1,400 before build and usage fees. Keeping WhatsApp active for further months costs separately.
For private saving, ask the builder to connect Gammal Tech sign-in and register the correct website address in your project. If requested, open the developer area, select the project or create it under the agreed quote, and copy its ID; never guess it. Check that the final site address is registered before testing saves. Each account has its own data. Test save and reload, then ask a trusted person using their own genuine account to check that your records are not visible. Do not share sign-in codes or create another account for yourself. User-data storage is free, with a 1 MB limit per user, so keep short text records rather than files or photographs. Paid sign-in codes may need project funds after the free allowance: fund your wallet, then transfer a usage budget to the project in the developer area. Sign-in does not automatically disclose identity or contact details to the site owner.
Service steps and prices reviewed on 18 October 2026. Check the amount shown in your account before paying. WhatsApp steps · Hosting and renewal
5. Adapt and send this request
Replace every bracketed placeholder with your real details. Copy this request after the assistant confirms build mode. Do not publish the illustrative figures as your own.
Build a private one-page purchase request register named [tool name] on MeNooN. Use Gammal Tech login and separate per-user storage. One coordinator records information and decisions received outside the tool; do not invent shared databases or approval permissions across accounts. Each request needs a reference, reason, item, specification, quantity, required date, unit price, delivery, confirmed extra charges and estimate source. Show the total and distinguish missing values from confirmed zero. Include draft, awaiting decision, approved, declined, needs information, ordered, partly received and complete states. Approval is manually recorded with decision-maker, date, confirmation reference and amount or quantity limits; it must not place an order. If approved cost, quantity or specification changes, preserve the earlier decision and return the request to review. Record ordering and receipt manually, and flag receiving more or fewer units than requested before closing. Do not send purchase orders or collect sensitive credentials. Before execution, quote the one-time build fee separately from the first month of standard one-page hosting at EGP 100, disclose additional usage charges and wait for approval.
6. Test the result before relying on it
- Enter two items at 250 each plus fifty delivery and a clear reason.Expected result: The estimate is 550 and the request remains awaiting decision, not approved merely because fields are complete.
- Try approval without a reference, then record a 550 limit and increase quantity to three.Expected result: A reference is required. The changed estimate becomes 800 and needs review while retaining the previous approval.
- Record one received item against a request for two and try to close it as fully received.Expected result: One item remains outstanding and requires explanation. Partial receipt is not silently treated as complete fulfilment.
- Save, sign out and return, then try a negative quantity and blank unit price.Expected result: Decision history remains private. Negative quantity is rejected and the unknown price is highlighted rather than treated as free.
7. Use the project during its first week
Begin the week with three small requests at different stages: a new need, one awaiting a decision and one awaiting delivery. Check that each has a next action and someone you will contact outside the tool, rather than only a coloured status. After a price or specification change, review whether the earlier approval still applies. At the weekly close, compare completed requests with what actually arrived and keep partial deliveries open until resolved. The goal is clarity about need, decision and execution, not creating ceremonial approvals or transferring authority to the register’s owner.
Your first weekly review note
Purchase review note: [website link]. [Number] requests await a decision and [number] await receipt. I will recheck [reference] because its quantity or cost changed after the earlier approval, before taking the next purchasing step.
Questions about this project
Does an approved label mean the system authorised the purchase?
No. You record a decision received from the appropriate person outside the tool. The application does not confer their authority or automatically verify who approved and what powers they hold.
Should everyone share one login?
No. Do not share credentials or verification codes. This design serves one coordinator’s private records; a shared workspace with several permission levels requires a different verified design.
Why does a price change require review again?
An approval may apply to a specific amount, quantity or specification. Preserving that decision and highlighting the change is more accurate than treating it as blanket approval for later alterations.