Parking of Olh

I'm looking for a specialist (preferably with experience working with OLX) who can help conduct market analysis and test existing solutions for quickly obtaining new listings from OLX. Important condition: All services in the report must operate strictly within the legislation of Ukraine and the rules of the platforms themselves. The number of services should be up to 5, this will be sufficient. Goal: to select the best service in terms of monitoring speed / price. What needs to be done: 1. Find active services/bots on the internet or in Telegram that monitor new OLX listings with minimal delay. 2. Test their speed and effectiveness. 3. Create a comparative table: service name, notification speed, usage conditions, tariffs (prices) (per month/per year). Please, indicate in your bids whether you have experience working with OLX monitoring systems. It would be a plus if you suggest a service you already use, or other options or developments. Best option: a ready-made service, it should not be a development from scratch. Important addition: the report should exclude the site mxsender, we used it a long time ago but were not satisfied with it for many reasons. We want a higher quality service.

Task: one dashboard with all business metrics — advertising, funnel, payments, manager performance, revenue planning. Data is pulled automatically via API. Scope: only the YCL direction (employment in Europe). Kommo has other directions — only YCL funnel deals will be included in the repository (filter by funnel/tag to be agreed upon).1. Data Sources (Integrations) Kommo CRM — leads, deals, funnel stages, responsible persons, sources, dates of transitions between stages (must keep history), reasons for refusals, custom deal fields (see point 2). Stripe — payments, amounts, statuses (success/failure/refund), linked to deals. Meta Ads — expenses, impressions, clicks, CPL, leads by campaigns (currently operational). Google Ads, Reddit Ads, LinkedIn Ads — planned; architecture — extensible connectors without core rework. SEO/organic— Google Search Console + GA4. Cross-link: traffic source → lead in Kommo → payment in Stripe (UTM, deal ID in Stripe metadata — propose the mechanism). 2. Mandatory Cuts (Deal Fields in Kommo) Each metric must be filtered/grouped by: Client Citizenship (Kenya, Nigeria, India, etc.). Residence Status: lives in their country / expat (already in Europe). These are two different segments with different cycles, conversion rates, and checks. Country of Placement / Service: Poland, Serbia, Slovakia, Germany (ZAV). Manager, team, traffic channel, period. If any fields are missing in Kommo — the executor indicates which fields need to be added, the client adds them.3. Funnel and Leading Indicators Data by funnel, for each stage — summary and leading metrics: Traffic → lead: leads, CPL by channels + day-to-day expense/click dynamics. Lead → qualification: conversion + first response speed, touches/calls to the manager per day, unanswered leads. Qualification → contract/invoice: conversion + sent offers, stalled deals (days in stage above norm). Invoice → payment: payments, average check + unpaid invoices, failed payments. Summary: revenue, ROMI by channels, run rate to monthly plan. 4. Deal Cycle Average and median lead → payment cycle (business benchmark ~4 weeks), cycle trend over time. Breakdown of cycle by stages (how many days a deal sits at each stage) — to see which stage is dragging. List of deals that have stalled at a stage longer than normal. Cycle breakdown by segments: citizenship, residence status, country of placement, manager. 5. Early Warning of Decline (Key Block) Since the cycle is ~4 weeks, today's leads = payments in a month. The system must: Compare leads/qualifications of the current week with the moving average (4 weeks) and issue an alert if there is a downward deviation: “leads -X%, with a 4-week cycle expect a payment decline in the week [date].” Build payment forecast for 4 weeks ahead from the current pipeline: deals at each stage × historical conversion of the stage × remaining cycle. Highlight in red weeks where the forecast is below plan — with time to react. 6. Additional Payments and Sales Planning In the Kommo deal card, the date and amount of the planned additional payment are stored. The system must: Collect a calendar of upcoming additional payments: total expected, by weeks/months. Highlight overdue additional payments (date passed, no payments in Stripe) — a separate list for follow-up. Calculate the monthly plan as: plan − already paid − scheduled additional payments = how many new sales are needed (in money and in deal units at average check). Weekly schedule: additional payments + forecast of new payments against the weekly plan. 7. Manager Performance Daily snapshot for each manager: touches/calls, conversations, sent offers, payments — for each day separately, with a chart over the period. Progress on personal plan compared to monthly pace (ahead / on pace / behind). Benchmarking with colleagues. 8. Visualization and Roles “Traffic lights” (green/yellow/red) for key metrics relative to norms/plans; progress scales; trend graphs; mobile adaptive. Roles: CEO — everything; COO — entire funnel and managers; team lead — their team; manager — their metrics and position relative to colleagues. 9. Reports and AI Automated reports on schedule (daily summary, weekly report) in the dashboard and/or messenger. Free-form queries (“how has CPL from Meta changed over 2 weeks?”) — LLM over the repository. Alerts in the red zone and according to the rules from points 5–6. 10. Technical Expectations and Staging Repository (PostgreSQL/BigQuery or equivalent) + ETL: Kommo webhooks + periodic synchronization (15–60 min). Frontend: custom or BI tool — propose with justification; requirements for roles, traffic lights, forecasts, and AI queries must be implementable. Stages: (1) audit and metrics map → (2) MVP: Kommo + Stripe + Meta, funnel, traffic lights, roles → (3) deal cycle, early warning, additional payments and plan → (4) SEO, AI reports, alerts → (5) new advertising channels. Payment is staged, with a demo for each stage. In the response, indicate: similar projects (end-to-end analytics), stack with justification, timeline and cost estimates by stages, monthly ownership cost (hosting, tokens, licenses).

A specialist is needed to collect and structure open information about sellers from marketplaces. It is necessary to determine the possibility of automated data collection and to form a database of sellers. In your response, please indicate: which marketplaces you have experience working with; what data you can obtain (seller name, link, categories, rating, number of products, other available fields); examples of similar projects.

Technical task Project Configuration of filling and synchronization of two Prom.ua stores with suppliers of auto parts. Task It is necessary to implement the loading and updating of products from auto parts suppliers for two online stores on Prom.ua. ⸻ 1. Connecting suppliers It is necessary to connect suppliers through: Supplier API; XML, CSV, XLS price lists; or another available method of obtaining products from the supplier's website. It is important to ensure complete synchronization of products between the supplier and the Prom.ua stores. ⸻ 2. Filtering and selection of products It is necessary to implement the ability to select products during import based on the following parameters: Car brand; Category of parts; Subcategory of parts; Other available characteristics. Example: For each store, there should be the ability to separately determine which categories of products and which car brands need to be loaded. Additional requirements for product selection It is necessary to implement the ability to select products during import not only by car brands and categories of parts but also by product availability status. There should be the ability to configure the following scenarios: Import only products that are in stock with the supplier; Do not import products with the status "out of stock"; Disable or remove products from Prom.ua after they are out of stock with the supplier. During pricing configuration, there should be the ability to combine filters: By car brand; By category of parts; By subcategory; By product availability. Example: Import only parts for Volkswagen and Audi, category "Braking system", that are in stock with the supplier. It is also necessary to implement a mechanism to prevent duplication of products from different suppliers. If the same product is present with multiple suppliers, only one product record should be imported into the catalog. Criteria for selecting a product when duplicates are detected: Priority is given to the product that is in stock with the supplier; If the product is in stock with several suppliers, priority is given to the product with the lowest price; If the cheapest product is out of stock, the system should choose the cheapest product among those that are in stock; Duplicate products from other suppliers should not create separate entries in the catalog. Example: Import only parts for Volkswagen and Audi, category "Braking system", that are in stock with the supplier. If the same part is available from several suppliers, only one entry is imported into the catalog — from the supplier with the lowest price among those who have the product in stock. ⸻ 3. Import of product cards During import, the following should be automatically loaded: Product name; Article; Photos; Product description; Price; Product characteristics; Manufacturer; Other available parameters. ⸻ 4. Updates It is necessary to set up automatic: Price updates when changed by the supplier ⸻ 5. Removal of unavailable products Products that are no longer in stock with the supplier should: Be disabled; or Be removed from Prom.ua (by agreement). ⸻ 6. Filling the stores It is necessary to: Create a category structure; Create subcategories; Correctly distribute products across categories; Check the correctness of product import. ⸻ 7. Work results After the work is completed, there should be: Suppliers connected; Product import configured; Price updates configured; New product addition configured; Disabling or removal of unavailable products configured; Prom.ua stores fully filled and ready for operation.

A Telegram bot is needed for automatic searching and monitoring of "BUY IT NOW" cars at auctions in the USA (Copart, IAAI). The bot should operate automatically and send notifications about new cars that meet the specified filters.Main functionalityFilter settings: 1. Car brand; 2. Model; 3. Year of manufacture (from/to); 4. Fuel type; 5. Engine volume; 6. Mileage; 7. Price range; Bot functions: 1. Automatic monitoring of new lots; 2. Checking for updates every 1-2 minutes; 3. Protection against duplicate notifications (anti-duplicate); 4. Ability to add and remove filters through the bot menu; 5. Saving settings of already existing car searches. Message format: 1. Photo of the car (4 photos); 2. Title and lot number; 3. Year of manufacture; 4. Mileage; 5. Engine type and volume; 6. Buy it now price; 7. Link to the lot.