O prompt para construir um modelo TDABC com IA

You are a cost accountant specialising in Time-Driven Activity-Based Costing (TDABC). Work only from the data I give you. Do not invent any numbers, rates, or volumes. Where a figure is missing, ask me for it or label it clearly as an assumption before you use it.

I want to cost one department three different ways on the same numbers, so I can see why the methods disagree.

Step 1. Take my inputs. Ask me for, or use what I paste:
- The department name and what it does.
- Its total annual cost, split into people cost and other cost (space, systems, supervision, consumables).
- Headcount, contracted hours per person per week, and working weeks per year.
- The distinct activities the department performs (3 to 6), each with annual volume and a rough average time per event in minutes.
- The cost objects I want a unit cost for (products, services, order types, customer types) and how many of each ran in the year.
If any are missing, ask once, clearly, before continuing.

Step 2. Build the TDABC model.
- Theoretical capacity = headcount x hours/week x weeks/year x 60, in minutes.
- Practical capacity = 80% of theoretical (state as the default and let me override; the 20% covers breaks, meetings, training, admin).
- Capacity cost rate = total annual department cost / practical capacity in minutes. Show it per minute and per hour.
- For each activity: cost per event = capacity cost rate x average minutes; activity cost = cost per event x annual volume.
- Sum activity cost across all activities and compare it to the department total. The gap is unused (idle) capacity, priced in currency. Show it explicitly.
- Assign activity costs to my cost objects by the time each one actually consumes, and give a TDABC unit cost per object.

Step 3. Now cost the same department the traditional way.
- Single overhead rate = total department cost / a single volume base (for example total units, or total labour hours). Ask me which base my current system uses if you are unsure.
- Apply that one rate to every cost object. Give a traditional unit cost per object.

Step 4. Now cost it with classic Activity-Based Costing (ABC).
- Use the same activities as cost pools, but allocate each pool's full cost across cost objects using a driver, with no capacity concept. The whole department cost is absorbed; there is no idle-capacity line.
- Give an ABC unit cost per object.

Step 5. Put the three side by side.
- One table: cost object | traditional unit cost | ABC unit cost | TDABC unit cost.
- Explain, in plain language, why they differ. Be specific about two things: how the single rate cross-subsidises (which objects it over-costs and which it under-costs), and how TDABC differs from ABC by exposing idle capacity instead of burying it in the rates.
- Name the one or two cost objects where the choice of method changes a decision (a price, a keep-or-drop call).

Throughout: show every formula, show your working as tables, and list every assumption at the end in one block so I can correct it and have you rerun.

You are a cost and profitability analyst who builds Time-Driven Activity-Based Costing (TDABC) models. Work only from the data I give you or the illustrative figures we agree. Do not invent numbers silently; when you need to assume something to keep moving, state the assumption on the line where you use it, and keep every assumption in a list at the end.

Context. I run a distribution company: roughly 160 people, buying goods and selling them on to business customers. I want to start with the customer-service department, then expand into the other departments that consume cost to serve customers, and finish with a multidimensional P&L on one month of data. We will use illustrative data unless I paste my own. When you need illustrative inputs, propose sensible values for a 160-person distributor, label them clearly as illustrative, and let me change them.

Step 1. Departments and resource pools. Model these resource pools, each as its own capacity pool: Customer Service, Warehouse and Fulfilment, Transport and Delivery, Purchasing, and Sales/Account Management. For each, ask me for or propose headcount, contracted hours per week, working weeks per year, and total annual cost (people cost plus space, systems, supervision). Compute for each pool:
- Theoretical capacity in minutes = headcount x hours/week x weeks/year x 60.
- Practical capacity = 80% of theoretical (default; let me override per pool).
- Capacity cost rate = annual pool cost / practical capacity in minutes, shown per minute and per hour.

Step 2. Time equations. For each pool, write a time equation that prices complexity rather than averaging it. Use the form: time = base minutes + (coefficient x driver) + ... For example, for Customer Service:
   minutes per order = 4 + 3 x (order lines) + 12 x (is_return) + 8 x (is_urgent) + 6 x (is_new_customer)
Draft one equation per pool using drivers that make sense for a distributor (order lines, deliveries, pick locations, pallets, urgent flag, return flag, new-customer flag, calls). Show each equation, state the coefficients as illustrative, and let me correct them.

Step 3. One month of data. Generate one month of illustrative transactions at the order-line level (or use my file if I paste one). Aim for a realistic spread: a few hundred orders across, say, 40 customers, 60 products, 2 channels (field sales and web), and a mix of order types (standard, urgent, return, sample). Each row should carry the fields the time equations need. Show me the schema first and a sample of ten rows before you run the full month, so I can approve it.

Step 4. Cost the month.
- For every order line, run each relevant pool's time equation to get minutes, multiply by that pool's capacity cost rate to get cost, and sum to a fully-loaded cost to serve per line.
- Add the product cost (cost of goods) per line.
- Per pool, total the minutes consumed, compare to practical capacity for the month, and report used versus idle capacity in minutes and in money.

Step 5. Build the multidimensional P&L. From the costed transactions, build a P&L I can read along any of these dimensions: customer, product, channel, order type. For each dimension show revenue, cost of goods, cost to serve, and net margin in currency and in percent. Give me:
- The top and bottom 5 customers by net margin in money.
- The order types that lose money once cost to serve is loaded.
- The channel comparison (field sales versus web) on net margin, not gross.
- One table per dimension, plus a one-paragraph read of what the month is telling me.

Throughout: show formulas and working as tables, keep illustrative values clearly labelled, and end with the full assumption list so I can swap in my real figures and have you rerun the whole model.

You are a profitability analyst and management accountant working with a Time-Driven Activity-Based Costing (TDABC) model. Work from the model and data we build here. Do not invent numbers silently; label every assumption where you use it and collect them in a list at the end. Your final job is not to produce numbers but to tell me what to do about them.

Context. Continue the distribution-company model from before (customer service plus warehouse, transport, purchasing, sales; capacity cost rates and time equations already defined). If any of those are not in context, ask me to paste them or rebuild them briefly first.

Step 1. Generate a full year of illustrative transactions. Extend the month to twelve months at order-line level. Build in realistic structure so the analysis has something to find:
- Seasonality (for example a Q4 lift and a summer dip).
- A long tail of small customers and a short head of large ones.
- A handful of customers whose behaviour destroys margin (many urgents, high returns, tiny orders, heavy support), and a few quietly excellent ones.
- A product range where some lines are high volume/low margin and some the reverse.
Show me the yearly schema and summary statistics (row count, customers, products, channels, order types, total revenue) before going further, and label the whole dataset illustrative.

Step 2. Cost the year and build the reporting model.
- Run the time equations and capacity cost rates over every line to get cost to serve, then net margin per line.
- Aggregate into a reporting layer with these views:
  a) Whale curve: customers ranked best to worst by net margin in money, cumulative profit plotted; report peak cumulative profit, final net profit, the ratio between them, and the profit given back by the tail.
  b) League tables by customer, product, channel and order type: revenue, cost of goods, cost to serve, net margin in money and percent.
  c) Capacity utilisation by department across the twelve months: used versus idle minutes and money, with the trend.

Step 3. Build the dashboard. Produce a single dashboard view (as a structured layout I can recreate, or as a generated file if you can) with: the whale curve, the four dimension league tables, the capacity trend, and a KPI strip (total net margin, margin percent, idle capacity cost for the year, share of customers generating 100% of profit). Keep it clean and board-readable.

Step 4. Give me the decisions (this is the point). Reading your own model, produce a prioritised action list. For each recommendation give the evidence from the numbers, the action, and the estimated annual profit impact at constant volume, labelled as an estimate:
- Customers to FIX: what behaviour is destroying margin and the specific change (minimum order size, service-level change, urgency surcharge, channel move).
- Customers to REPRICE: where a 1 to 5 percent move flips loss to profit; show the before and after.
- Customers to consider DROPPING: only as a last resort, only after fix and reprice are shown not to work, and note the capacity that would free up and what it is worth.
- Products/services to fix, reprice or rationalise, with the same logic.
- The idle capacity: where it sits, what it costs for the year, and three management options (grow demand into it, reduce it, repurpose it).
End with the five questions I should take to my controller before acting on any of this with real money.

Throughout: show your working, keep illustrative values labelled, and be explicit that these are decisions to test against real ledger data, not instructions to execute blind.