A customer brings a used phone to your shop. Staff need a purchase offer that leaves room for inspection, refurbishment, selling fees, shipping, returns, and the merchant's target contribution. A comparable-listing median cannot answer that question by itself.
Build the tool around three separate records: reviewed market evidence, your resale planning scenario, and an approved conditional offer. SoldFetch supplies listing observations. Your business owns the expected selling channel, costs, commercial assumptions, and decision to buy.
This guide follows one fictional handset through that workflow. All amounts, observations, thresholds, and staff actions are synthetic. They demonstrate arithmetic and controls, not current device prices or a recommended buying strategy.
Start with a reviewed device cohort
The used-electronics comps guide covers model, capacity, carrier, functionality, bundle, and condition matching. Reuse that process before designing a quote screen. Keep working unlocked handsets separate from locked devices, repair projects, accessories, and mixed lots.
Retrieve candidates through GET /v1/scrape using supported parameters such as keyword, ebaySite, sold=true, itemCondition=used, count, and page. Detailed battery, cosmetic-grade, activation-lock, and refurbishment decisions belong to your own review layer. exactMatch=true does not verify device identity.
Keep listing IDs, source URLs, currency, price basis, retrieval timestamps, and warnings. Search soldPrice values are displayed listing amounts; accepted-offer payments and sale dates are not independently verified. A reviewed cohort improves comparability without changing those limitations.
Choose a merchant-owned resale scenario
Our eight accepted synthetic displayed item amounts are GBP 280, 300, 310, 320, 320, 330, 340, and 360. Their median is GBP 320. That describes the selected observations; it does not establish the revenue your shop will realize.
The merchant selects GBP 300 as planned item revenue after reviewing its own channel, warranty obligations, selling history, and expected device condition. Record why that assumption differs from the comp summary. It should be editable by authorized staff and versioned independently of the evidence.
Keep the revenue and comp amounts on a consistent item-only basis. The example treats outbound shipping as a merchant cost. A different channel might collect delivery charges or assess fees on a broader total; model those amounts explicitly. Do not substitute unknown shipping or costs with zero.
Subtract the costs before setting a ceiling
Use one currency throughout. The example's local policy requires at least five reviewed comps retrieved within 48 hours. These are merchant-defined gates, not SoldFetch guarantees or universal minimums.
| Planning input | Synthetic GBP scenario |
|---|---|
| Planned item revenue | 300.00 |
| Selling fee, 10% of planned item revenue | 30.00 |
| Outbound shipping | 12.00 |
| Refurbishment | 18.00 |
| Handling | 8.00 |
| Returns reserve | 12.00 |
| Target contribution, 20% of planned item revenue | 60.00 |
| Maximum acquisition amount | 160.00 |
The fixed costs and reserve total GBP 50. Calculate the ceiling as planned revenue minus modeled selling fees, fixed costs, reserve, and target contribution. This leaves GBP 160 available to acquire the device.
The target is a contribution margin on planned revenue after the listed costs. It is not net profit: rent, tax, financing, and other overhead require explicit treatment if relevant. A reserve is a planning allowance, not a promise that returns will cost that amount.
Keep margin separate from markup
At a GBP 160 acquisition amount, modeled total costs are GBP 240: acquisition 160, fee 30, and fixed costs/reserve 50. The remaining GBP 60 is a 20% contribution margin because 60 / 300 = 0.20.
Markup uses a different denominator. The same GBP 60 is 25% of the modeled GBP 240 cost base. Applying a 20% markup does not produce a 20% margin. Name both the denominator and included costs wherever staff can change the target.
The offline calculator uses Decimal and rounds the fee to cents before flooring the ceiling. Its core example is:
from decimal import Decimal, ROUND_FLOOR, ROUND_HALF_UP
revenue = Decimal("300.00")
fee = (revenue * Decimal("0.10")).quantize(
Decimal("0.01"), rounding=ROUND_HALF_UP
)
fixed_costs = Decimal("12") + Decimal("18") + Decimal("8") + Decimal("12")
target = revenue * Decimal("0.20")
ceiling = (revenue - fee - fixed_costs - target).quantize(
Decimal("0.01"), rounding=ROUND_FLOOR
)
# ceiling == Decimal("160.00")
A production fee model must follow the merchant's actual channel rules. The synthetic percentage here deliberately excludes minimum fees, tiers, and tax complexity.
Test a downside scenario before approval
Change planned item revenue to GBP 280 while retaining the same percentage fee, margin target, and GBP 50 fixed costs/reserve. The fee becomes GBP 28, target contribution GBP 56, and ceiling GBP 146.
That comparison exposes how the offer depends on the merchant's revenue assumption. It is not a statistical confidence interval derived from the eight comps. Staff should choose and document an approved scenario rather than automatically selecting the highest ceiling.
Withhold a quote when evidence is sparse, stale, unreviewed, or in a different currency. Missing costs and invalid amounts also require a hold. If costs leave no positive acquisition amount, return an explanation with no offer value. Clamping a negative result to a customer-visible GBP 0 quote hides an infeasible scenario.
Give staff a reviewable quote screen
Keep the evidence and commercial decision visible together without merging them into one authoritative market price.
| Screen section | What staff should see |
|---|---|
| Device | Merchant identity, expected condition, unresolved inspection items |
| Evidence | Reviewed count, displayed-price median, source links, retrieval age |
| Scenario | Planned revenue, channel, fee basis, costs, reserve, target margin |
| Decision | Ceiling, proposed amount, reviewer, rationale, version, expiry |
| Customer offer | Conditional amount, inspection assumptions, expiry and next step |
A ceiling is an internal approval boundary. Staff may approve a lower amount. In the base scenario, a GBP 150 conditional offer leaves modeled contribution of GBP 70, or 23.33% of planned revenue. The app records the reviewer and checks the amount against the current ceiling before issuing it.
Make inspection, expiry, and versions enforceable
The conditional offer should state the expected device identity and condition, required functionality and lock checks, and validity period. This example expires offers after 24 hours; your merchant policy determines the appropriate duration.
Record scenario and policy versions with the approved amount. At inspection, compare the actual device with the assumptions. A failed lock check, condition mismatch, expired offer, or changed version requires a fresh quote or an explicit review path. Do not silently reduce an offer or treat a preliminary calculation as final payment authorization.
Keep the original approved record when revising a quote. A later cost update should create a new scenario version so staff can explain which assumptions produced each customer offer.
Run the complete workflow offline
Download the standard-library Python calculator and run it with Python 3.10 or later:
python3 electronics-trade-in-quote-tool.py
The synthetic example prints:
Base: review_required | ceiling GBP 160.00 | modeled contribution GBP 60.00
Downside: review_required | ceiling GBP 146.00 | modeled contribution GBP 56.00
Staff: conditional offer GBP 150.00 | modeled contribution GBP 70.00 (23.33%)
It makes no network requests. Self-checks cover arithmetic, missing inputs, insufficient or old evidence, infeasible costs, staff approval, inspection failures, expiry, and version changes. Use those failure cases when wiring the workflow into your application.
Budget refreshes and launch one cohort
Keep credentials on your server and queue bounded refreshes. Each successful search page or item lookup consumes one unit, including authenticated cache hits; additional pages are separate operations. Reuse your stored evidence deliberately while displaying its age. Rate and concurrency limits are shared across workspace keys. Consult current pricing and dashboard Billing for available limits; an SLA applies only if expressly agreed in a signed agreement.
A paid SoldFetch plan permits transformed valuations and a small selection of linked listing examples under Terms section 9.2, subject to third-party rights and the restrictions on raw access and bulk redistribution. Show the evidence limitations beside the quote workflow.
Start with one device cohort, one resale channel, and a staff approval queue. The related collectibles valuation app, marketplace price suggestions, and inventory pricing dashboard guides apply the same separation between listing evidence and your product's decisions.
