Check the total before the chart.
All sales: 125. Tea only: 100.
Try the total checkCourse you opened
Forasm picks
Current English-language offers rated 4.2+ on Udemy, across work and tech subjects. Coupons first; no more than four picks from one subject in All. Practice-test-only and malformed listings are excluded. Ratings aren’t a Forasm course review or a ranking of every course on the web.
Keep handy
All sales: 125. Tea only: 100.
Try the total checkCOUNT(*) → 2 rows
SUM(sales) → 100Two Tea sales—40 and 60—share one group.
See the queryCompare the answer with its source before acting on it.
Build a checked workflowAI strategy & governance
Work through a small pilot before committing to a big rollout.
See it in action
A fictional support team wants to save time. Compare what each idea would actually change.
A bounded pilot to investigate
The output is a draft. Staff can compare it with the order facts and policy before anything reaches a customer.
No automatic sending, refunds or changes to an account.
Try a routine delay, a missing order ID, conflicting policy and a refund request. Record corrections as well as time.
Work the numbers
Fictional timing for 100 replies. Tool, setup and monitoring costs are not included.
The essentials
“Reduce reply-handling time” gives you something to measure. “Use AI everywhere” does not. Compare against the current process and a simpler non-AI option.
Drafting faster is useful only if checking and correcting the draft does not eat the saving. Measure the whole task, not just model response time.
Name the person who can pause the pilot, the errors that trigger a pause, and the manual process the team returns to. A reviewer needs time, information and the ability to reject the output.
Keep something useful
A filled example plus a blank version. No account needed.
Only if the draft takes three minutes AND needs no further work. In this example, three minutes of review reduce the saving to two minutes.
Approval is weak if the person cannot see the source policy or is expected to rubber-stamp every draft. Test the review process too.
A small test can reveal problems; it cannot establish safety across every user, exception or change in the system.
Go deeper
Related resources, not a requirement to use the example.
Excel · reliable totals
Make a tiny total you can verify by hand. Then trust your dashboard a little more.
See it in action
Edit one sample sale. The source total and the Tea-only total update together.
| Product | Sales |
|---|---|
| Tea | 40 |
| Coffee | 25 |
| Tea |
Change the highlighted sale.
Tea only
10040 + 60 = 100
All sales: 125
Enter a number from 0 to 10000.
=SUMIF(A2:A4,"Tea",B2:B4)This demo calculates locally. It is not connected to your spreadsheet.
The essentials
Use a header row, one product column and one numeric sales column. Do not insert a subtotal into the same source rows that a formula will add.
SUMIF matches “Tea” in A2:A4 and adds the corresponding B cells. Both ranges need to line up. The expected answer here is 40 + 60 = 100.
If a chart is filtered to Tea, compare it with the Tea total—not the whole table. Check source range, selected category and whether new rows were included.
Keep something useful
Three fictional sales. Paste the formula into a separate cell.
125 includes Coffee. Check the chart’s category selection before changing the formula.
Check whether its source range includes the new row. An Excel Table can help maintain a growing source range.
Keep summary cells outside the source rows, or they may be counted again.
Go deeper
Related resources, not a requirement to use the example.
SQL · grouping & joins
Follow three orders through a GROUP BY—and see how a join can quietly inflate them.
See it in action
The query works until each order joins to two matching customer records. Switch the example to see why.
| customer | amount |
|---|---|
| Maya | 40 |
| Omar | 25 |
| Maya | 60 |
SELECT customer, SUM(amount) AS total
FROM orders
GROUP BY customer
ORDER BY customer;Without a join
3 source rows → 3 rows to sum. Every order is counted once.
| customer | amount | record |
|---|---|---|
| Maya | 40 | A |
| Maya | 40 | B |
| Omar | 25 | A |
| Omar | 25 | B |
| Maya | 60 | A |
| Maya | 60 | B |
Toy names keep the example short. Use a stable key and check its uniqueness in a real system.
The essentials
Here, one row is one order. If another table contains two records for the same customer ID, joining it can create two rows for each order.
Maya has 40 + 60 = 100. Omar has 25. The grouped results must add back to 125 when all orders are included exactly once.
Check join keys and whether the matching side is unique at the intended grain. SUM(DISTINCT amount) is not a repair: two genuine orders may have the same amount.
Keep something useful
Self-contained PostgreSQL practice query. No real customer data.
The database checks syntax and types, not whether you intended to count every order twice.
That can remove legitimate equal-value orders as well as duplicates. Fix how rows match.
Use ORDER BY when output order matters; GROUP BY alone does not promise presentation order.
Go deeper
Related resources, not a requirement to use the example.
This topic link is incomplete or unavailable.
Browse courses →