Disclosure: I built Split-Up. This article was prepared with AI assistance and checked against the product’s documented capabilities. The example is fictional and shows arithmetic, not a customer story or a claim about measured results.

Begin with the items, not the payment request

Imagine three friends: Asha, Bikash and Chandra. Their restaurant bill contains:

The starter is shared, but it is not shared by everyone. Asha and Bikash each take Rs 120 of it. Chandra’s share remains the cost of Chandra’s own meal.

That gives agreed shares of Rs 420 for Asha, Rs 520 for Bikash and Rs 200 for Chandra. These add back to the bill total: Rs 1,140.

An equal split among all three would be Rs 380 each. That arithmetic is valid too, but it describes a different agreement. Choose the allocation openly instead of allowing the calculator to make the decision for the group.

Record who paid separately

Now suppose Asha paid Rs 740 and Bikash paid Rs 400 to the restaurant. Chandra paid nothing yet. The payments also add up to Rs 1,140.

Compare each person’s payment with their agreed share:

Asha has covered Rs 320 beyond her share. Bikash can pay Asha Rs 120, and Chandra can pay Asha Rs 200. The balances then return to zero.

Notice that Asha paying most of the bill did not change what anyone ordered. Likewise, changing who shares the starter should change the allocation before you calculate the remaining payments.

Check a scanned bill against the original

If you use a bill scanner, compare the extracted items and amounts with the actual receipt. Look for a missed small item, a duplicated line or a wrong amount. Review who shares each item as well: recognizing a price does not establish who consumed the item.

This example deliberately leaves out discounts, service charges and tax. For a real bill, account for every charge actually present and agree how to allocate it. Do not assume that a restaurant must add a particular charge.

Where Split-Up fits

Split-Up supports equal, exact-amount, percentage, share and itemized splits, as well as several payers on one expense. It tracks running balances for friends and groups.

It does not move money. Wallet IDs and QR codes help people make a payment through their chosen service; the receiver confirms receipt. A displayed balance and a completed payment are different events, so check both.

You can use the same allocation-first method on paper. The useful habit is making the agreement visible before sending anyone a payment request.

Try Split-Up.

What causes more confusion at your table: deciding who shared an item, or remembering who already paid?

Disclosure: I’m the founder of theBotBazar. This article was prepared with AI assistance and checked against the product’s documented capabilities. The workflow below is a proposed manual preparation exercise, not an automatic feature or a measured result.

Build a map from questions to sources

Start with the questions people already ask. Use a small, anonymized set rather than uploading private customer conversations. Remove names, order details and other identifying information before making a public example.

For each question, record a source, an owner and a gap:

This is a fictional worksheet. It does not describe a customer deployment or theBotBazar dashboard.

The final column is often the useful one. An empty source cell tells you to write or update the answer. A source without an owner tells you that it may become stale. Two conflicting pages tell you to resolve the disagreement before asking a bot to choose between them.

Test the answer and the passage separately

Once the material is ready, try a question whose answer is explicit. Read the answer, then open the cited source and inspect the passage. Does it support the particular claim, or does it merely mention the same topic?

Next, ask about something the material does not cover. Observe what happens; do not assume a refusal behavior simply because a system uses retrieval or displays citations. Record unsupported details as failures to investigate.

Then add an exception. A page might describe a general delivery area while another section lists an exclusion. A useful test asks about the excluded case. An answer can sound reasonable while missing the condition that changes it.

Keep the question, expected supporting passage, source version and actual answer together. Those notes make the next evaluation comparable. They also separate a content update from a change in the bot’s behavior.

Treat content maintenance as part of the setup

A website crawl can collect a page. It cannot decide on behalf of your business which conflicting policy is authoritative. Resolve that choice with the person responsible for the information.

When the business changes an answer, update the source and repeat the questions that depend on it. Record what you observed. A previous good answer does not establish that a new source version will behave the same way.

For sensitive or account-specific requests, give readers a clear route to a person. Do not put private customer records into a public article or test fixture.

Where theBotBazar fits

theBotBazar is a no-code builder that can train bots on documents, websites and Q&A pairs. Answers can include source citations. Those capabilities give you material to inspect; they do not replace checking whether the source actually supports an answer.

The worksheet is useful even before you choose a product. If you can connect a recurring question to a current source and a responsible person, you have something concrete to test.

Product documentation: theBotBazar docs.

Which support question still sends your team looking through old messages?