From sample request to weekly report: making the field visible

Published anonymously at the client’s request. No company or system details are shared.

Where it started

In a company selling industrial products, a sale does not end with a conversation. The customer wants to try the product, a sample is requested, the sample is sent, and then everyone waits for a result. That cycle can run for weeks, and each step is followed by a different person.

Data was not missing at this group. Sales reps were out in the field, visits were happening, samples were going out. What was missing was a collective view — management could only answer “what happened this week” by asking people one at a time.

What we built

Sample requests became records

We built a dedicated structure for sample requests. The sales rep enters the request from their own screen, it lands in the system, and the relevant people are notified automatically.

The important part: the request is matched against the corresponding order on the ERP side. In other words, “has the sample been sent” is a question asked of the system rather than of a person. The matching runs as a scheduled job, so no manual chasing is needed during the day.

The Turkish character problem

A detail that looks small but touches every part of the project: Turkish characters. The same customer name may be written with “Ş” in one system and “S” in another. If matching does not account for that, the right record is never found and the system reports that no such customer exists.

We put character normalisation at every point where matching happens — sample-to-order matching, sales rep assignment, inbound email routing. This kind of detail is the invisible but decisive part of any integration running in Turkey.

Inbound email reaches the right account

We built a routing layer so that email arriving at the company attaches itself to the relevant customer record. In a group operating several brands and domains this is more involved than it sounds: which domain belongs to which company has to be defined.

Weekly activity reporting became automatic

Weekly reporting used to be prepared by hand. We automated it: the system compiles the week’s activity, produces a report and emails it out as a PDF.

The report can also be viewed on screen. Making the two look the same took extra work — a layout that sits correctly on screen does not necessarily survive conversion to PDF. It is the kind of detail that reminds you a design has to be verified separately for each medium.

What we learned about using AI

The summary section of the report uses AI. It worked well — but we took a lesson from it that is worth sharing.

When AI is used inside an automated process, the consumption cost has to be measured up front. A job that runs once a week looks inexpensive; but if you do not account for how many records it runs across and how many times, the bill can be a surprise.

Setting up something similar today, we measure against a limited data set first, confirm the cost, and only then roll it out. That is not avoiding AI — it is making it something you can budget for.

Outcome

For management, what changed is that “what happened in the field this week” now arrives without anyone being asked. For the sales rep, a sample request stopped being something to chase and became something they record.

What we would do differently

We would design the report for both media together from the start. Designing for the screen first and converting to PDF afterwards means fixing every place the layout breaks, one at a time.

We would also put consumption monitoring on automated jobs from day one. Monitoring added later only shows the problem once it has already happened.