Scope and Hand Over a Small BotMarketing Shop Setup
By BotMarketing.pro published updated
A small implementation is easier to accept when it has a defined outcome. For a freelancer or no-code consultant, that outcome could be a three-product catalogue where a buyer places an order and the shop owner finds it and agrees collection.
Consider a fictional candle shop. The BotMarketing launch package, prerequisites, order workflow, acceptance checks and handover below describe a bounded engagement. They are not a real customer story or an earnings promise.
Define the outcome of one package
Replace “automate your business” with the number of product cards, an observable action and the person who will handle orders. For example:
Prepare one goods category in BotMarketing with three ready-made products: a small jar candle, a large jar candle and a gift set. Connect the shop's bot, check the catalogue and MiniApp ordering route, and give the owner a short operating guide.
The shop approves descriptions, photographs, prices and stock. Acceptance depends on the agreed order journey and the owner's independent actions. Custom manufacture, external synchronisation and daily order processing are outside this package.
Record when source material will be ready, the service fee, included revisions and the period for questions after handover. Agree those values for the actual project; the label “no-code” does not establish that an accounting connection exists. Use the agency implementation requirements table when choosing between an existing product and separate development.
Check prerequisites before configuration starts
- The shop owner controls the company account, sign-in methods and Telegram bot. Specialist access has the necessary permissions and fits the subscription's limits.
- Approved names, contents, photographs, prices and actual stock exist for all three products. Batch availability does not have to be guessed.
- A named person answers buyers, agrees payment and collection, and reconciles stock after sales outside the service.
- Buyers are comfortable with Telegram; the required language, currency and plan have been checked for the workflow and market.
- Essential external connections are listed. If launch depends on one, do not begin it as ordinary configuration before checking interfaces and delivery scope.
Connecting the bot requires its token. Telegram recommends treating that token like a password: exclude it from acceptance notes, screenshots and the general operating guide. Use fictional data and a separate client role for checks; a referral account does not replace a company account.
Configure the order journey in BotMarketing
The shop sells ready-made goods. In this example, the small candle has finite stock of 10 units; leaving stock blank would mean unlimited availability.
- The company prepares the catalogue. It adds three active products to a goods category, with descriptions, photographs and prices. It sets stock, enables ordering and connects its bot. The specialist checks that buyers see the intended cards in the MiniApp.
- The buyer places an order. From the bot, they open the MiniApp, choose the small candle, add two units to the cart and leave a collection request at checkout. The service checks quantity and creates the order. This batch's stock decreases from 10 to 8.
- The owner processes the request. In Orders, they open the entry and see the product, quantity and comment. They agree collection time and payment with the buyer. A buyer's request is not itself an agreed arrangement.
- The shop fulfils the order. The owner arranges payment and handover. The order preserves context but does not prove payment or delivery. Sales outside the service need separate stock reconciliation; automatic candle manufacture is outside the journey.
Do not add reminders, loyalty or broadcasts merely to extend the feature list. The local goods shop guide covers the product workflow. Before offering it, follow the product assessment route and distinguish completed checks from documented capabilities.
Accept the working route, then hand over control
Agree the checks before starting. This table defines expected results; the people involved in the actual engagement fill in observed results, dates and open questions.
| Check | Expected result | Record |
|---|---|---|
| Catalogue scope | One category and three approved cards with correct prices | Product names, approved source and discrepancies found |
| Buyer journey | Two small candles and a comment reach the created order | Steps, fictional data and order reference |
| Batch stock | The small candle has 8 units left after ordering two from an initial 10 | Initial and final values; check zero-stock behaviour separately |
| Unavailable product | The buyer cannot order a zero-stock product | The card and observed behaviour rather than an assumption |
| Owner operation | The owner independently finds the product, quantity and comment in Orders | Who completed the action and any clarification needed |
| Independent control | The owner signs in and knows how to edit cards and request help | Checked access, guide location and responsible contact |
A sample acceptance record
The agreed cards and order journey were checked using fictional data. Observed results, date and test order were recorded in the table. The owner independently opened the order and found the comment. Incomplete checks are listed separately with a responsible contact and next action.
Client decision: accepted, accepted subject to listed conditions, or not accepted against a specific check. Additional products and integrations require a separate request.
Fill this sample with actual results. Do not record a successful check in advance or hide an incomplete essential step behind “everything works”. The record helps agree the delivery state; its format and applicability depend on the parties' agreement.
A client handover checklist
- Confirm that the owner signs in using their own method and controls the company and bot independently of the freelancer's personal account.
- Give the owner the three-product list, approved description sources and procedure for updating prices and stock.
- Ask them to open an order, locate its comment and explain how they agree payment and collection.
- Provide the short guide, acceptance results, open questions and routes to the specialist and product support.
- End agreed specialist access when delivery finishes; arrange any continuing access and support separately.
Price delivery separately from possible commission
The client pays the service for its subscription and the specialist for scoped configuration. Referral commission is a separate possible reward from the provider. Explain the relationship before registration: “I may receive commission if you register through my link and pay for a subscription under the applicable terms; my service fee covers the listed package.”
Standard terms for a new partner account are 30% during the first year from the referred user's registration and 5% afterwards. Check your own and company-specific conditions separately. The friend code cookie lasts 30 days; a partner-linked promo code takes priority for company registration, and UTM labels do not replace the code. Accrual and payout differ; the partner programme terms explain the details.
Price the package using actual delivery, revisions and support without treating future commission as guaranteed. Distinguish an agreed configuration error from a new requirement: a fourth product, migration or an external integration changes scope. Before additional work, record the new action, acceptance check, price and timeline. The client can then identify the outcome being purchased, and the specialist has a defined end to the engagement.