Build a Client Revision Tracker That Keeps Versions and Decisions Clear

1. Gather these details

• Choose a fictional project with three versions labelled consistently, such as version 01, 02 and 03. Avoid calling several different files the final version.
• Prepare three short revision requests containing one change each. Separate a colour adjustment from a text correction so their progress can be reviewed independently.
• Decide where original files and correspondence remain. The tool records a clear reference; it should not make a private document public merely to simplify retrieval.
• Define the meaning of each status before building. Completed work and customer acceptance are separate events and need labels that preserve that distinction.
• Prepare an anonymous confirmation example with its date, communication channel and relevant version. A short decision reference is usually enough without copying entire conversations.

2. Define how the project works

1. Identify every delivered version

Give each delivery a separate version number, sending date and brief description. Put that number in the message accompanying the file so the recipient knows what they are reviewing. Never replace an old version reference with a newer file: previous requests could then appear to describe different work. Preserve the sequence even if a later design reuses material from an earlier version. Consistent identifiers make the rest of the register useful.

2. Turn messages into specific requests

For each revision, record a concise request, the version reviewed and its exact location. If someone asks for a larger heading, establish which heading on which page. Mark ambiguous requests as needing clarification and ask through your normal conversation. Do not guess and later record the guess as the customer’s instruction. Include a source reference and date so you can understand the request without rereading the entire history.

3. Record completion without implying acceptance

After making a change, record what actually changed and the new version sent. Move its status to awaiting confirmation, not closed simply because your editing is finished. Preserve the original request for comparison. If a new request follows delivery, create another entry and decide whether it is a correction within the agreement or a scope change requiring a new discussion about effort, price and timing.

4. Close requests with an identifiable confirmation

When confirmation arrives, record its date, reference and the version it covers, then close the request manually. Ask a brief clarifying question when approval is ambiguous. The tool does not read WhatsApp, verify who sent a message or treat silence as approval. During your weekly review, start with older waiting items and follow up yourself. Do not assume the system has sent reminders or obtained decisions in your absence.

3. Work through an example

One closed request does not approve an entire version. Record the actual scope of confirmation rather than changing every project item together.

4. Set up your account and start the build

1. 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.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.

Open the developer area

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 single-page revision register called [tool name] on MeNooN. Use Gammal Tech login and separate per-user storage. One account owner maintains their own register; do not create a shared customer or team database. Include short project labels, version numbers, sending dates and revision entries tied to the reviewed version. Each entry needs the original request, affected location, source reference, status, completed change and replacement version. Use statuses new, needs clarification, in progress, awaiting confirmation and closed. Closing must be a manual action requiring a confirmation date, reference and version. Do not treat silence as approval, read messages or send automatic reminders. Preserve the original request when completion details change, and confirm destructive deletion. Do not collect identity documents or credentials or publish private file references. Provide project search and a filter for waiting requests, with a clear mobile interface. Before execution, quote the one-time build cost separately from the first month of standard one-page hosting at EGP 100, disclose any chargeable login-code usage, and wait for approval.

6. Test the result before relying on it

1. Record a request against version 01, complete it in 02 and supply no confirmation.Expected result: It remains awaiting confirmation. A completion date alone must not label it closed or accepted.
2. Try closing the request with an empty confirmation reference or version.Expected result: The tool requests the missing evidence reference or keeps the entry awaiting confirmation.
3. Create two requests, close one with evidence and leave the other needing clarification.Expected result: Filters show one closed and one unresolved item. The project is not automatically approved as a whole.
4. Save, sign out and sign in again, then cancel a deletion request.Expected result: Records retain their versions and dates; cancelling deletion preserves the item. Signed-out visitors cannot see the records.

7. Use the project during its first week

Start with one current project and transfer its open requests with their references. Avoid spending the first day archiving years of correspondence. After each delivery, take two minutes to update the version and status. At the end of the week, compare the register with the messages: every closed item should have relevant confirmation, and every waiting item should have a known next action. Simplify unused fields if necessary, while preserving the four essentials: request, version, completed change and confirmation. They are the reason this tool exists.

Your first weekly review note

Weekly revision review: [website link]. There are [number] requests awaiting confirmation and [number] needing clarification. Next I will follow up on [project reference] and identify the reviewed version before closing its remaining requests.

Questions about this project

Does the client need an account?

No. You maintain a private record of decisions received through ordinary communication. This project does not assume a shared workspace or permissions across your account and a client account.

Should I upload every project file?

Not necessarily. Start with clear references while retaining files in their normal location. Do not publish customer documents simply because a public link would be easier to paste.

What if confirmation does not name a version?

Use context only when the connection is unambiguous; otherwise ask which version was reviewed. The tracker should reduce ambiguity, not turn a general reply into approval for every change.