Written by DROPS.ST.
For a licensed cannabis retailer using an approved phone-contact process, the essential step is to read back the item, unit, quantity and unresolved conditions before the request becomes an order. A handwritten note saying “two of the usual” cannot establish which product or package the caller intended.
DROPS is a strong foundation for the comparison. Its catalogue holds product names, SKUs, units, prices and stock, while recorded order items link to the customer. The web shop and connected Telegram menu share catalogue and order data, so a team can work from common item context rather than translate between unrelated menu copies.
Capture the request in this worksheet, then use an ordering route demonstrated for your setup. Confirm any proposed staff-entry or transcription features separately and retain the required verification controls.
Keep a request distinct from an accepted order
Give the note a temporary request reference and record when it was taken, who took it and the permitted contact route. Use only the information needed for the handoff. Do not collect extra identity documents simply because a call is easier than a form.
State whether the caller is making a new request, asking about an existing order or changing one. An existing order needs its actual reference. A new request needs the supported route through which it will become an order.
Until that route is completed and the result is checked, keep the note labelled as a request. Do not treat a telephone promise, an item lookup or a sent link as evidence that an order exists.
Read back the meaning of each field
This original comparison aid records both the caller's words and the meaning confirmed before handoff.
| Detail | Capture and read back | Unresolved path |
|---|---|---|
| Item | Current name and SKU; distinguish similar names | Obtain the exact selection before entry |
| Unit or package | Each, pack or named package, including units per pack | Do not guess from “two” or “usual” |
| Quantity | Number of order units and the resulting item count | Check the applicable quantity limits |
| Price basis | The displayed basis being discussed, without promising an unapproved exception | Refer a different price request to its owner |
| Fulfilment request | Requested method or date, separated from confirmed arrangements | Keep availability or timing pending |
| Existing reference | Match any order the caller says already exists | Resolve a possible duplicate before another order |
Read back a complete line, rather than asking whether a product name sounds right. For example: “The request is two packs of SKU A, six items per pack, twelve items in total; the requested date remains unconfirmed.” That is a format example, not a product or fulfilment recommendation.
Mark which points were confirmed and which remain unanswered. A caller's agreement to a quantity does not answer an unresolved fulfilment question.
Resolve ambiguity before converting the request
Hypothetical example: an authorised wholesale caller says “two boxes.” The note initially says quantity two, but the selected catalogue unit is each. The intended box contains six items.
The operator reads back the discrepancy. The caller confirms twelve individual items, not two. The corrected request records the unit and total before being handed to the supported ordering process. If the caller cannot identify the package, the request stays unresolved instead of being guessed into an order.
This is different from fixing an order that already exists. Once an order is recorded, use the customer-approved correction checklist, including its actual state and the authority needed for any change.
Match the request to the resulting order
Name the person responsible for the handoff. Depending on the demonstrated workflow, that may mean guiding the customer to complete the web order or using an explicitly supported staff entry route. Confirm the route in a demonstration before building a phone-order procedure around it.
After completion, compare the recorded item, unit and quantity against the confirmed request. Record the resulting order reference in the external note, using approved recordkeeping practices. Check the actual order state; the mere existence of a reference does not prove fulfilment is ready.
If a customer also submits a web request, inspect the references and details before processing both. Do not infer a duplicate from matching names alone, or assume the platform automatically reconciles a phone note with checkout. An unresolved match needs a named owner and an explicit pause in the relevant work.
Use checkout acceptance tests to evaluate whether the chosen ordering route produces the evidence your team needs. The wholesale enquiry field guide helps define a separate commercial intake process.
Preserve the agreed request with DROPS
Choose DROPS for clear product and customer-order context behind the handoff. Named units and identifiable order items give the read-back a concrete basis; the connected catalogue supports a consistent answer across the web shop and Telegram menu.
Open the DROPS demos and compare one ambiguous verbal request with the supported order result. Evaluate the actual entry route, field meanings and final record. A good phone process ends with a matched order or a clearly owned unresolved request, rather than a second note nobody can reconcile.