What business gets done with an AI agent

Build a P&L for [period] broken down by business unit using 1C data. For each unit: revenue, direct costs, gross profit, overhead, profit before tax. Next to it — the share of total company revenue. Allocate indirect costs only by the rule [by revenue / by payroll / by floor area]. If no allocation base is set, don't spread them evenly — put such costs on a separate line "not allocated". Build the report on the accrual basis: from sales documents, not from cash receipts. Output an XLSX: a "P&L" sheet with units in columns, a "Details" sheet linking to the documents behind each line item, and a "not allocated" line with its total.

25 min · once a month

Merge Wildberries and Ozon sales for [period] and compare with [the previous period / the same period last year]. For each marketplace, category and SKU show revenue, orders, average order value and returns. Break every decline down into factors: order count fell, selling price fell or returns grew — and show each factor's contribution in rubles. Don't explain a decline by "falling demand" or "seasonality" until you show a figure that confirms it. If an item didn't sell because it was out of stock, say exactly that — that isn't a demand decline. Output a SKU table sorted by lost revenue, and the ten items that account for half of the decline.

25 min · once a week

Write replies to new Ozon and Wildberries reviews for [period] following the tone rules from [the attached file / the examples below]. Split the reviews into three groups: reply with a template, reply individually, do not reply — and for each group name the signal you used to decide. In the reply, state the substance of the complaint in your own words, do not open with "thank you for your review". Do not promise deadlines, refunds, discounts or replacements — nobody has confirmed those. Where the customer directly asks for goodwill compensation, leave [operator decision] in the text and move the review into the "for a human" group. Output a table: review, rating, SKU, group, reply text, what to fill in by hand.

20 min · every day

Reconcile the bank statement [Tochka / Alfa / Sber — or the attached file] against the postings in 1C for [period]. Match operations by amount, date and payee. Collect separately: receipts and payments not posted in 1C, postings with no bank operation, amount discrepancies within a single operation, likely duplicates. Don't force pairs: if an operation matched only by amount but not by payee or date — put it in "needs a decision", not in the matches. Output an XLSX: a "Discrepancies" sheet linking to the operation number and source document, a "Matched" sheet and a total line — how many operations and what amount did not reconcile.

20 min · once a month

Build a receivables report by customer as of [date] using 1C data. For each customer: the amount owed, which documents it consists of, the payment term from the contract, days past due, the date and amount of the last payment. Count overdue days from the contractual term, not from the shipment date. If the term is not filled in — don't assume a standard 30 days, move the customer into a "term not defined" list. Sort by overdue amount. Flag separately those whose debt has been growing for three months in a row, and those who pay reliably but late. At the end — the total overdue amount and which five customers account for half of it.

10 min · once a week

Prepare a reconciliation statement with [counterparty] for [period] using 1C and Diadoc data. Match every UPD and VAT invoice from EDI against a posting in 1C by number, date and amount. Collect the discrepancies: a document exists in Diadoc but isn't posted in 1C, is posted in 1C but never arrived via EDI, amounts or the VAT rate differ, the document was cancelled or replaced by a corrected one. Don't stop at a matching number: different contracts can share the same numbers — also check the contract and the amount, otherwise move the row into "needs a decision". Output the statement in the standard form broken down by dates and documents, a separate discrepancies sheet and the opening and closing balances — per our data and per the EDI documents.

20 min · once a quarter

Check outgoing payments on the accounts for [period] against the statement and the postings in 1C. Find: payments with a matching payee and amount within [3 / 7 / 14] days, the same invoice or UPD paid by different payment orders, recurring payments that have no contract or acceptance certificate in 1C, and increases in the amount of a recurring payment. Don't treat scheduled recurring payments — [rent, leasing, payroll project] — as duplicates. Don't declare a payment a duplicate if the grounds differ: if the payment descriptions differ, move the pair into "looks similar, needs checking". Output a table: date, payee, amount, source document, suspicion type and the possible overpayment amount; at the end — how much money is worth reclaiming or cancelling.

15 min · once a month

Build a payment calendar for [horizon: a week / two weeks / a month] based on account balances and the obligations in 1C. Lay out the outflows by day: invoices due with their deadlines, taxes and contributions, payroll, loans and leasing, recurring payments. Mark which payments cannot be moved. Include expected customer receipts as a single inflow line per day and only where the contractual payment date has already arrived; don't count sales reps' promises or "they usually pay by Friday". Find the first day the balance drops below the [minimum balance] and show the shortfall. Output a day-by-day calendar and a list of payments that are candidates for moving, with a new date.

15 min · once a week

Every morning at [time] send a Telegram summary of the accounts [list of accounts] for the previous day. Format: opening and closing balance for each account and in total, total inflow and outflow, the three largest receipts and the three largest payments with payee and description. In a separate block — unusual operations: a payment above [threshold], a new payee never paid before, a payment on a weekend, a fee higher than usual. If there were no operations — say exactly that, don't resend the previous summary and don't fill the gap with average values. Keep the message within one screen: no tables and no explanations of why the balance changed.

10 min · every day

Check the attached invoice [PDF / photo / EDI document] before sending it for payment. Cross-check against 1C: tax ID, tax registration code, bank account and bank — against the supplier record; the subject, prices and amount — against the contract and this supplier's previous invoices; whether the same invoice has already been paid or is already in the queue. Take the details from the body of the invoice, not from the email or the sender's signature. If a field is unreadable or missing in 1C, write "not verified" and don't substitute the value from a previous invoice. At the end: what matched, what differed, whether there is a duplicate, and a verdict — pay, clarify or reject, with a one-line reason.

5 min · on an event

Build a revenue dashboard in Google Sheets by channel [Ozon / Wildberries / others — list them] and refresh it [every Monday morning]. Overwrite the "Data" sheet in full, don't touch the charts sheet — it references "Data". Don't wipe the history of previous weeks: each week is its own row. If a source didn't respond or returned an obviously incomplete period — don't substitute a zero and don't carry the previous week over. Leave the cell empty, put the week into a "Gaps" sheet with the reason and mention it in the update message. After every run send a short summary: what was refreshed, which channels didn't come through, and the revenue change versus the previous week in one line.

25 min · once a week

Analyze Wildberries returns for [period] and compare with [the previous period]. Calculate the return rate against orders for each SKU, category and warehouse. Break it down by the reasons from the marketplace report; keep defects, "wrong size" and "doesn't match the description" separate — those are different areas of responsibility. Don't explain growth by seasonality until you show the same happened last year. If there is no data for last year, say so. Single out SKUs where the return rate is more than one and a half times the category average, and estimate the losses including logistics. Output a SKU table and the five items to start with.

30 min · once a month

Merge sales from 1C, Bitrix24, Ozon and Wildberries for [period] into a single table. Match items by [SKU / barcode / the attached mapping reference], not by name. Bring units of measure and currency to a single form, and fix whether we count revenue with or without VAT. Remove duplicates: one shipment that landed both in 1C and in the CRM as a deal is one row. If an item didn't match, or matched only on a similar name — don't merge it by eye, move it to a "Not matched" sheet with the candidate options. Output an XLSX: a "Sales" sheet broken down as date — channel — unified SKU — quantity — amount, a "Not matched" sheet and a "Mapping reference" sheet that I can extend.

30 min · once a month

Calculate margin by SKU by week for [period] using Ozon and Wildberries sales and cost of goods from 1C. For each week break the selling price down into marketplace commission, logistics, discounts and promos, and cost of goods. Find SKUs whose margin deviated from their own average for the period by more than [threshold]. For every deviation name the factor with a figure: how many rubles came from the increased commission, how many from the discount, how many from purchase cost. Don't name a cause if the breakdown doesn't show it — write "factor not determined". Take cost of goods as of the shipment date. Where it's missing, don't substitute the category average, move the SKU into a "no cost of goods" list. Output a table by SKU and week and the top deviations in rubles.

25 min · once a week

Compare [month] with [the previous month] across Ozon, Wildberries and 1C sales. Show revenue, order count, average order value and returns — in total, by channel and by category. For each row give the change in rubles and in percent and state what produced it: more orders or a higher average order value. List separately everything that makes the months non-comparable: a different number of working days, marketplace promos, a large one-off order, unsettled returns. Show large one-off deals both in the total figure and as a separate "excluding one-offs" line. Count revenue by [shipment / payment] — the same way for both months. Output a comparison table and the five categories that drove most of the change.

15 min · once a month

Calculate the sales funnel from [Bitrix24 / amoCRM] data for [period] and compare with [the previous period]. For each stage: how many deals entered, how many moved on, the conversion into the next stage and the end-to-end conversion from the first stage, the mean and median time in status. Count from the transition history, not from the deal's current status. Show deals that skipped a stage on a separate line rather than spreading them across the adjacent ones. Don't give a list of specific deals or recommendations on them — only figures and the differences between periods. If a stage has fewer than [30] deals, mark its conversion as unreliable and don't draw conclusions from it. Output a table by stage with the two periods side by side and the three stages with the largest conversion drop.

20 min · once a month

Calculate ad cost share for every campaign for [period]: Yandex Direct and the ad dashboards of Ozon and Wildberries. For each campaign: spend, revenue by the dashboard's attribution, ad cost share, order count, average order value. Within a single platform use one attribution model and state which one. Don't add up revenue from different dashboards for the same order — that's double counting. If a campaign's revenue can't be tied to its spend, move it into "attribution not determined" rather than crediting it with the category's overall sales. Separate campaigns with an ad cost share above [target] from those with too little data for a conclusion: at spend below [threshold] or fewer than [20] orders, mark the row as unreliable. Output a table of campaigns in descending order of spend and a bottom line: how much budget went into campaigns with an ad cost share above target.

20 min · once a week

Build a payables report for suppliers as of [date] using [MoySklad / 1C] data and the account balances from Tochka. For each supplier: the amount owed, which delivery documents it consists of, the payment term from the contract, days past due, the date and amount of the last payment. Take the term from the contract or the delivery terms. If the term isn't filled in — don't assume the usual 14 days, move the supplier into a "term not defined" list. Spread the payments across the days of [period] so that the balance covers each day. If it doesn't — show the day and the size of the gap instead of silently trimming the amounts. Output an XLSX: a "Payment queue" sheet with date, amount and the reason for the priority, a "Deferred" sheet and a total line — how much is due and how much money is available.

20 min · once a week

Go through the tickets from Telegram, Avito and email that arrived between [shift close time] and [opening time], and assemble a queue for the morning. Put the urgent ones on top: [payment went through, goods never arrived / repeat ticket about the same problem / threat of a complaint or a return]. Below them — questions about availability and delivery times. Attach a draft reply to routine tickets. If the reply needs an order status that is not in the correspondence, do not guess it — put [check in 1C] and leave the ticket for an operator. Output a list: time, channel, customer, substance in one line, urgency, draft or "needs a human".

15 min · every day

Watch new reviews on Ozon and Wildberries and flag only what threatens the rating. Threshold: rating [1–2]; or [3] and below for an SKU from the list [priority SKUs]; or [2] negative reviews on one SKU within [24 hours]; or the words [defect, scam, swap, court, consumer protection agency]. One review — one alert, do not write about the same one twice. Do not raise an alarm for a rating without text or for a review about the marketplace's delivery — collect those in a separate summary once per [period]. In the notification: SKU and name, rating, date, the full quote from the review, the listing's current rating and how much it moved, how many reviews this SKU got in [7 days].

15 min · set up once

Go through the customer complaint from [the Telegram correspondence / the email] and propose goodwill compensation strictly by the rules in [the attached file]. First pull out the facts: what was bought and when, what went wrong, what the customer asks for verbatim, which ticket this is in order. Whatever is not stated in the correspondence — mark "not specified", do not fill it in. Then find the matching rule clause and name its number. If no clause fits or the amount exceeds the limit — say so, propose the closest option within the rules and send the case for approval instead of stretching the rule yourself. In the draft reply do not promise deadlines, refunds or replacements beyond the chosen clause. Output: facts, rule clause, proposal, draft letter.

10 min · on an event

Collect the recurring questions from tickets in Telegram, Avito and email for [period] and turn them into knowledge base articles. Group by the meaning of the question, not by matching words: "when will it arrive" and "where is my parcel" are one article. Take only topics that occurred at least [N] times, put the rest in a "rare" list. The title uses the customer's wording, the answer comes from real operator replies with a link to the source ticket. Where operators answered differently, do not pick the correct version yourself: show both answers and mark the article "needs a decision". Output articles with the fields question, answer, source, ticket count — in descending order of frequency.

30 min · once a week

Sort the tickets from Telegram, Avito and email for [period] by topic and count the load by week. Take the classifier from [the attached list of topics] or build your own and show it to me before the analysis. One ticket — one topic; a conversation stretching over several days counts once, by the date of the first message. For each topic: tickets per week, change against the previous week, distribution by day of week and by hour [time zone]. A spike caused by a promotion, an outage or holidays goes on a separate line and is not mixed into the trend. Output a "topic × week" table, a "day of week × hour" table and the three fastest growing topics.

20 min · once a month

Merge the new messages from Telegram, Avito and email for [period] into a single queue. Merge messages from one customer into a single thread by [phone / email / order number]. If only the name matched — do not merge: keep the rows separate and add a "possible duplicate" flag. Set the order like this: the primary key is [waiting time], with equal waiting time these go higher: [repeat ticket / mention of payment or a refund / customer with status X]. Do not write replies: each row contains only the substance of the ticket in one phrase. Output a queue: time of the first message, how long it has waited, channel, customer, substance, priority and the condition it was assigned by.

15 min · set up once

Build reply templates from the Telegram and email correspondence for [period]. Identify the situations that occurred at least [N] times, and write a template for each in the tone from [the attached examples]. Everything that changes case by case — name, order number, deadline, amount — stays as a field [in square brackets]; do not fill in a typical value, or the operator will send someone else's deadline. Do not write deadlines, refunds, discounts and goodwill compensation into the text: put a field [decision per the rules] and note who is entitled to fill it in. For each template: when to use it, when not to use it, what to fill in. Output a table of templates in descending order of situation frequency.

30 min · once a quarter

Build a report on ad channels for [period — week from … to …] using data from Yandex Direct, VK Ads and Metrica. For each channel and campaign: spend, clicks, conversions on goal [goal name in Metrica], revenue from that goal, ROMI and the change versus [the previous week]. Calculate ROMI only where revenue comes from Metrica. Where there is no revenue — don't substitute an average order value and don't carry it over from another channel, move such channels into a "ROMI not calculated" block and write what is missing. Don't explain a drop by seasonality until you show the same week a year ago. Output XLSX: a sheet by channels, a sheet by campaigns and five lines of conclusions — what grew, what fell and where to move budget.

20 min · once a week

Write [5] post variants for the launch of [product and what changes in it] for [Telegram / VK]. Audience: [who they are, what they already know about us, what stops them]. Offer and deadline: [what we offer]. Make the angles different: usefulness, a specific pain, "before and after", handling an objection, news. Rely only on the facts I gave. Don't invent numbers, deadlines, testimonials or client names: if a fact is missing for a strong line — leave a [gap] and write what to fill in. Take the tone from the attached posts, not from ad templates. Output for each variant: the angle in one word, text within the platform limit, a call to action and a line "who it's aimed at".

15 min · on an event

Find where in Yandex Direct spend over [period] produced no result on goal [goal name]. Go down the levels: campaign, ad group, ad, search phrase and ad network placement. Include in the report only rows with spend above [threshold] — don't draw conclusions on smaller samples, collect them in a separate "not enough data" line. Don't call a row wasted spend if it has conversions that are simply expensive: separate "no conversions at all" from "cost above target" — those are different decisions. Separately show phrases with high CTR and zero conversions, and ad network placements with a bounce rate above [80%]. Output a table: level, name, spend, clicks, conversions, what you suggest doing (pause / add as negative / lower the bid) and how much money that frees up over [period].

20 min · once every two weeks

Write a chain of three abandoned-cart emails: [how many hours until the first], [the second], [the third]. Make the mechanics different: the first — a reminder and removing a technical barrier, the second — an answer to the reason for hesitation [delivery / price / size choice], the third — a deadline [what exactly is limited]. Write only about what I listed. Don't invent discounts, free delivery, "only 2 left", testimonials and ratings: if a mechanic requires such a block — put [filled in from data] and describe where the value comes from. For each email: three subject line variants and a preheader, the text, one button with its label, the send time and the condition under which the email doesn't go out (order paid, item out of stock).

25 min · set up once

Compare prices for my items on Wildberries with competitors using MPStats data as of [snapshot date]. My SKU list: [article numbers or category]. Treat a competitor as comparable only on a match of [category, volume/size, composition, brand segment]. Don't compare different pack sizes and bundles with single items — move such pairs into "not comparable" and explain how they differ. For each SKU show: my price before and after discount, the median and the price range of competitors, the difference in percent, my stock and competitors' stock, the search position for [key query]. Flag items where I'm above the median by more than [10%] while orders are falling, and where I'm the lowest of all but sales aren't growing. Output a table by SKU and a short list: where the price is worth revisiting and in which direction.

20 min · once a week

Rewrite the listings [article numbers] on [Ozon / Wildberries]: title, specifications and description. Take buyer queries for this category and distribute them across the fields: the main ones — into the title and the first specifications, the rest — into the description, without listing them comma-separated. Write only from the specifications in the listing and from what I attached. Don't add composition, country of origin, warranty, certificates or product properties: if a field is empty, put [to clarify] and move it into the list of missing data. Respect the platform's field limits and don't repeat a single keyword more than [3] times. Output for each article number: the title, a specifications table, the description text, the list of queries used and the list of fields I have to fill in myself.

30 min · on an event

Link spend in Yandex Direct with leads in Bitrix24 for [period] via [source field / utm], reconcile conversions against Metrica. For each channel and campaign calculate: spend, number of leads in CRM, CPL, number of leads in statuses [qualified] and the cost of a qualified lead. Separately show quality: duplicates, spam and rejections with reason [not relevant], the share of leads left untouched for longer than [N hours]. Don't distribute leads without a source across channels proportionally — keep them as a separate line "source not identified" with their share of the total. Show the discrepancy between conversions in Metrica and leads in CRM as a number, don't smooth it over. Don't include revenue and deals in this report. Output a table by channels, a table by campaigns and three lines: where CPL grew, where quality fell at the same CPL, where leads aren't being worked.

20 min · once a week

Analyze the finished campaign [name, dates] in Direct and Metrica and propose [5] hypotheses for the next launch. Goal of the next launch: [what matters more — volume or cost]. Look where the potential sits: segments with good conversion and small reach, creatives with high CTR and a weak landing page, times and geographies with different cost per goal, devices, steps on the landing page where people drop off. Frame each hypothesis like this: what we change, which numbers from this campaign it's built on, the expected effect as a range, how we'll test it and on what budget. Don't pass off as a finding something explained by random spread on a small sample, and don't fit the explanation to a decision already made — if there isn't enough data for a conclusion, call it an idea for a test, not a hypothesis.

30 min · on an event

Calculate the economics of a [discount size] promo on [article number / product] on [Ozon / Wildberries] for [period]. Take the current price and the platform commission, cost from 1C, logistics, storage, acquiring and [ad cost share] for this product. Calculate margin per unit now and with the discount, the break-even sales uplift in units and percent, and profit in three scenarios: sales [+X%], [+Y%], [+Z%]. If I didn't specify some cost item — don't take a market average, put it as a "not accounted for" line and show how it moves the result. Separately calculate the cannibalisation effect: how many sales will shift from [adjacent article numbers] and what that means for profit across the group. Output a scenario table, the loss point and one line: at what uplift the promo makes sense.

20 min · on an event

Collect [10] topics for a content plan for [month] for [Telegram / VK]. First look at my publications over [period]: which formats and angles got above-average response, which topics repeated without result. Describe this in two or three lines before the topic list. Goals for the month: [warm-up / sales / audience growth] and events: [launch, season, date]. Each topic: format, angle, who it's for, which goal it leads to and which facts it's built on. Take facts only from my materials. Don't make up cases, result figures and client quotes: where an example is needed — put [case needed] and describe which one exactly. Don't propose a topic if it already ran on my channel within [period] — or say how the new angle differs. Output a table of topics and a week-by-week layout.

20 min · once a month

Go through the new leads in Bitrix24 for [period — yesterday / the last 24 hours / since the last triage]. For each: source, what they're asking for, budget ballpark, region, contacts, whether this company is already in CRM. Assign priority by the rules: [budget above threshold / target industry / repeat enquiry]. If there isn't enough data for priority — don't infer it from the company name and email domain, mark it "not enough data" and leave it in the general queue. Flag possible duplicates of open deals, but don't merge them. Output a table: lead, priority, suggested owner, deadline for first contact. As separate lists — duplicates and leads without contacts. Create tasks only after I confirm the list.

10 min · every day

Build a proposal for deal [number or deal name in Bitrix24], using template [link to document]. Take the legal details, contact person and scope of work from the deal card, prices — from [price list], payment terms and the discount — by the rules: [rules]. Don't fill blanks with plausible text: if CRM has no deadline, volume or contact person — leave a [to clarify] marker in the document and collect all such spots in a separate list at the end. Don't round or recalculate prices yourself. Output — a document following the template's structure, without extra blocks, followed by a list "what to clarify before sending".

15 min · on an event

Find open deals in Bitrix24 that have no active task or no activity for longer than [N] days, across pipelines [list of pipelines]. For each: amount, stage, owner, date and type of the last contact, date of the nearest task, if there is one. Count as contact only real activity — a call, an email, a meeting, a comment. Don't count a stage change or an automatic field update as contact and don't use it as a sign that the deal is alive. Group by manager, and within that by amount. Separately pull out deals with no owner and deals whose close date has already passed. At the end — how many deals in total and for what amount are stuck.

10 min · once a week

Find deals in Bitrix24 where a proposal was sent more than [N] days ago and there's no reply from the client, and prepare a draft follow-up email for each. Before the email, gather the context: what was in the proposal, what was agreed on the last call, which objections have already come up. Take the reason for writing from the communication history. If there's nothing in the correspondence to hook onto — don't invent the client's interest and don't refer to a conversation that never happened, write a short neutral email and mark it "no context". Don't offer discounts or new terms — only [permitted reasons]. Output a table: client, amount, days of silence, email subject — and the text of each email up to 120 words as a draft, without sending.

20 min · once a week

Build the [quarter] sales summary from Bitrix24 and amoCRM and compare it with [the previous period]. Give plan versus actual on revenue overall and by [breakdown — line of business / manager / region]: plan, actual, variance. For each manager: closed amount, number of deals, average deal size, share of the total actual. Separately — the five largest won and five lost deals with the stated loss reason. Don't add up deals from the two systems until you show that their stages and statuses are comparable; count what isn't comparable separately and say so. Build the forecast for the next quarter from open deals with a close date inside it, honestly stating the share of deals with no date. Output XLSX: "Plan vs actual", "Managers", "Deals", a totals line.

40 min · once a quarter

Find open deals in Bitrix24 and amoCRM above [threshold] that have been sitting at their stage longer than the norm: [stage — period; stage — period]. For each deal: amount, stage, how many days it's been sitting, owner, last contact, whose court the ball is in — ours or the client's. Take the reason it stalled from comments and correspondence. If it isn't there — don't infer the reason from the stage and the amount, write "reason not recorded" and set "find out the status" as the first action. For each deal propose one specific action for this week and state what you need from me. Don't calculate stage conversion percentages — a list of deals is what's needed. Sort by amount, with what can be closed before the end of [the period] on top.

25 min · once a week

Assemble the sales summary for the past week from Bitrix24 and send it to Telegram [day and time]. In the summary: closed amount and number of deals versus last week, movement on large deals, new leads and how many of them were picked up. For each manager — a short line: closed, in progress, activity. Separately name the areas of attention: whose result is falling for the second week running, who has no single contact on large deals, where the week fell outside the usual range. Don't call a one-off dip or spike a trend until it has repeated twice. Keep the summary to [15] lines: details — as a separate file on request.

10 min · once a week

Reconcile the payment promises from Bitrix24 deals against actual receipts in 1C as of [date] and find clients with no payment for longer than [N] days. For each: the promised date and amount, who recorded it and when, what actually arrived, how many times the deadline was pushed, the date of the last conversation, the owning manager. Link client and payment by legal details. If a payment arrived without a link to a deal — don't assign it to the nearest one by amount, move it into "unidentified payments". Don't reconstruct promises that aren't in CRM by logic: write "agreement not recorded". Sort by amount. For each client propose the next step: a call, an email, escalation or handover to receivables collection.

20 min · once a week

From the Ozon and Wildberries reviews for [period] collect only product change requests: what is missing, what people ask to add, what they ask to bring back. Do not take complaints about delivery, packaging and support into this list — count them on a separate line and stop there. Group the requests by meaning, not by wording. For each group: frequency, share of all reviews for the period, [3] verbatim quotes, the SKUs where it occurs. Do not turn a one-off wish into a trend: keep groups with fewer than [5] mentions in the "weak signal" section rather than in the main list. Output a table: request, frequency, share, quotes, SKUs.

15 min · once a month

Compare our product with [a list of competitors or links to their sites] on features and pricing, and put the result in a Google Sheet. For each competitor: pricing plans and prices, what each includes, limits and restrictions, the stated integrations, who they position themselves for. Back every price and every feature with a link to the page and the date you saw it. Whatever is not on the site — write "not published": do not infer it from a neighbouring plan, do not silently convert an annual price into a monthly one, and do not carry what reviews and roundups say into the table as a fact about the product. Output a "Matrix" sheet (rows — features, columns — competitors), a "Sources" sheet and a bottom line: where we are more expensive and which features we lack.

30 min · once a quarter

Build a draft PRD from [links to meeting notes, tickets, documents] and put it in Google Docs. Structure: the problem and who it hurts, what has already been tried, use cases, functional requirements, what is out of scope, success metrics, open questions. Mark every requirement with its source — a link to the note or a quote. If a decision was not made in the notes, do not make it for the team: move it into open questions as options and state who is responsible. Take only metrics we already know how to measure; for the rest write which data source is missing. Duplicate the requirements as a sheet in Google Sheets: number, wording, source, status.

25 min · on an event

Read the backlog tasks in [Yandex Tracker / Kaiten], queue [name], and score each one by impact and effort. Count impact by [revenue / churn / support load] and by the number of users affected; effort — by the team's estimate, if it is set on the task. Apply the [1–5] scale identically to all of them and attach a key explaining what each score means. Do not assign a score where the task has no description: collect those in a "nothing to score" list stating which information is missing. Do not pass your own guess about task size off as the team's estimate — mark where the effort came from. Output a table: task, impact, effort, the rationale for each score, quadrant — and the ten tasks worth taking first.

20 min · once every two weeks

Collect the feedback from Telegram, email and Ozon reviews for [period] and sort it by a single taxonomy [list of topics — or propose your own and show it for approval before the analysis]. One taxonomy for all three channels: the same topic is named identically in each. Assign every message to exactly one topic; put the debatable ones in "unclassified" and show them separately rather than splitting them across two topics at once. The channels differ in volume, so besides the count compute the topic's share within its own channel — compare shares, not counts. Do not add the channels together into one overall ranking. Output a "topic × channel" table: count, share within the channel, two quotes each — and a list of topics that exist in only one channel.

25 min · once a month

Go through the Telegram tickets and the Ozon and Wildberries reviews for [quarter] and identify the five main user pain points. Rank them not by mention frequency but by cost: how many users are affected and what happened to them afterwards — [left / did not buy again / reduced their basket]. State the effect on churn and repeat purchases only where you computed it from data you actually saw: attach which rows the figure was built from and how many people are in the sample. Where linking a ticket to subsequent behavior did not work out — write "effect not measured" and leave the pain point in the list by frequency, instead of grading it with words like "probably has an effect". Output five cards: the wording of the pain point, how many users are affected, [3] quotes, what happened to them afterwards — and, as a separate list, the hypotheses that the data does not confirm.

30 min · once a quarter

Break the feature [name and one or two sentences about its goal] into user stories and file them in [Yandex Tracker / Kaiten], in [queue or board]. For each story: the role, what they do, why; acceptance criteria as a list of checkable conditions; what is out of scope. Separately go through the edge cases: empty state, external system failure, missing permissions, repeated launch, cancellation midway. Do not invent requirements that are not in the description: where a decision has not been made, file a story marked "needs a decision" with the question inside, rather than your own assumption presented as a requirement. Output a list of stories with the dependencies between them and the order in which it makes sense to do them.

15 min · on an event

Build the week-by-week dynamics of negative reviews on Ozon and Wildberries for [period]. Count [1–2 stars] as negative. For each week: the share of negatives among all reviews that week, the number of reviews, a breakdown by complaint topic. Count the share specifically: growing sales lift the number of reviews too, and that in itself is not a rise in negativity. Mark the dates [list of shipped fixes] and for each topic show the share before and after. If less than [3] weeks have passed since the date or the week has fewer than [20] reviews — write "too early to judge" and do not call it an improvement. Output a week-by-week table, a breakdown by topic and a list of topics where the share of negatives has grown for the third week in a row.

20 min · once a week

Build a cash flow statement for [period] using 1C and bank data. Assign all receipts and payments to three sections: operating, investing, financing activities. For each section — line items with amounts, inflow, outflow and net flow; above and below — the cash balance at the start and end of the period. Don't count transfers between our own accounts or currency conversion as either a receipt or a payment. If the activity type for an operation isn't obvious, don't default it to operating — move it into "needs classification" with the amount and the payment description. Output an XLSX: a "Cash flow statement" sheet by section, a details sheet with links to the operations, and a control line — does the closing balance agree with the bank statement.

25 min · once a month

Calculate receivables turnover for [period] broken down by [months / quarters] using 1C data. Give company-wide figures: turnover in times, average days sales outstanding, average receivables for the period. Then the same metrics per customer and by groups [wholesale / retail / chains]. Calculate the average balance from monthly snapshots, not from the start and end of the period. If a customer has fewer than [three] shipments in the period, don't average their payment days — mark it "not enough data". Don't explain a change in the metric by seasonality or sales growth until you show the figures that confirm it. Output a Google Sheets table: company-wide dynamics, the customer breakdown, and a "not enough data" column.

20 min · once a month

Prepare three payment reminder texts and a schedule for sending them to the debtors from 1C. The first — [three] days before the due date, neutral: amount, invoice numbers, payment date. The second — on day [seven] past due, specific: how many days are overdue and what happens next. The third — on day [thirty], formal: referencing the contract clause on late payment penalties. Take amounts and document numbers only from 1C. If a customer has an unallocated payment or a dispute over an acceptance certificate — don't send the letter, move them into a "human first" list. Don't calculate penalties in the text if the rate isn't filled in in the contract: write "in accordance with the contract". Output three templates with placeholders, a sending rule for each and a list of exceptions.

20 min · set up once

Build a sales dashboard for [period] in [Google Sheets / XLSX] on 1C data. Arrange the file like this: a "Source" sheet — a flat table with no merged cells and a date column in a single format; a "Summary" sheet — pivot tables by [breakdowns]; a "Dashboard" sheet — charts and slicers tied to the pivots rather than to the source directly. Set the pivot ranges as whole columns or named ranges so that nothing shifts when a new export has a different number of rows. Don't hard-code calculated values into the dashboard cells: every figure must be recalculated from "Source". On a separate "How to refresh" sheet describe: where to paste the new export, what to click and what breaks if the column order in the export changes.

40 min · set up once

Generate a reconciliation statement with [counterparty] for [period] in SBIS and check it against the settlements in 1C. Match line by line: date, document, debit, credit. Collect separately the lines that we have and the counterparty doesn't, that the counterparty has and we don't, and those that match on the document but differ on the amount. Don't level out differing balances by fudging: the discrepancy must break down into specific lines, and if it doesn't, say so. Take the document's SBIS status into account: sent, signed, rejected, cancelled — an unsigned document cannot be treated as agreed. Output the statement in the standard form, a line-by-line discrepancy sheet indicating the side and the status, and the closing balance from both sides.

25 min · once a quarter

Process the incoming documents from Diadoc for [period] and match them against the orders and contracts in 1C. For each document: type, supplier, number, date, amount, EDI status, the order or contract found. Sort into groups: full match, price differs, quantity or item differs, details don't match the record, no order found, document not posted in 1C. Treat a discrepancy as significant from [deviation] — flag anything smaller but don't escalate it. Don't match items by similarity of the name: if the SKU or code doesn't match, write "not matched" instead of picking the nearest item. Output a table of documents indicating where each figure came from, and a separate list of documents awaiting signature for longer than [deadline].

15 min · once a week

Assemble the month-end document package for [month] using 1C, Diadoc and email data. For each customer, match the sale or service rendered against the acceptance certificate, the UPD and the VAT invoice: what is signed by both sides, what was sent and is hanging unsigned, and what is missing altogether. A document sent via EDI and not signed by the customer does not count as received — that's a separate status, not a closed position. Don't fill a gap with a similar document from an adjacent month: if the number and date don't agree with the sale, mark it "not matched". Output an XLSX: a customer sheet with the status of every document, a "missing" sheet with amounts, and draft letters to the customers on that sheet — one letter per customer.

25 min · once a month