Stop deciding blind.

The problem, and it was costly

On a sales stand, tasting is the first conversion lever: with nothing to taste, you do not sell. And it is not only about the product: without tasting cups, spoons or glasses, tasting stops too. All of this was ordered by eye. We opened the fridge and the cupboards, looked at what was missing, and ordered for the following week.

Two things made it unworkable. It was never the same people placing the order, so nobody remembered what had been used the week before. And busy periods arrived without being anticipated, while the delivery time did not get any shorter: ten days, sometimes two weeks. Over the end-of-year holidays, we ran short of several tasting supplies, and had to buy them in a hurry at the shop next door, at a price that had nothing to do with the supplier's.

What I built

An ordering file that answers a single question: how much do we need to order this week, and why.

• A weekly stock count of tasting products, on a fixed day, so that the measurement exists whoever is on duty
• The difference between last week's stock and current stock, which gives actual consumption rather than assumed consumption
• Reconciling what was ordered with what was received, two things everyone assumes are the same
• A target stock raised for busy periods, and a safety stock that includes the maximum delivery time
• A need calculated automatically, with an order recommendation readable without knowing anything about the file

What it changed

We went from "order by eye" to "manage with data". Anyone could place the order without having been there the week before, and busy periods were prepared for instead of endured.

The consumption analysis was useful beyond ordering: it identified the fast-moving products, the secondary ones, and above all the ones that were rarely offered for tasting, which meant we could stop ordering them for that purpose.

The problem

The client's request fitted in one sentence: people like this, in companies like this. Everything else had to be built. We had to cast a wide net over several regions to get volume, then filter twice: the companies first, on their size, their revenue band and a list of exclusion criteria, then the right people inside, on role, seniority and reporting line. Then their work address had to be found and checked one by one: a dead address damages the reputation of the sending domain, so it costs more than it brings in.

Huge raw volumes on one side, very precise criteria on the other, and nothing reliable in between. What came out could not be checked: there was no way of telling whether a delivered list was worth anything before the client had used it, which is too late.

What I built

The full chain, and above all its checkpoints. The job was not collecting, it was making quality verifiable before delivery.

• Written sourcing rules for each vertical: construction and infrastructure, logistics and transport, industry, petrochemicals and refining
• Cleaning, deduplication and standardisation, with tracking sheets that showed where the volume was being lost and why
• Qualification, then sample-based quality control before each delivery, with a completeness rate that was measured, not estimated
• Tutorials and operating procedures so that someone else could take over the work, which is the only proof that a process really exists
• A contact scoring system, from closest to the target to furthest away. In the field, quality is never completely even, so it might as well be said in the deliverable: the client knew who to call first instead of receiving a flat list

The automation test, and why I stopped it

I ran a test of AI automation on the qualification step, and I recommended stopping it. On that precise scope, the machine did not make the distinction a person made, and a badly qualified contact costs more than a contact not delivered.

It was my idea in the first place. Saying no to your own idea, with the figures to justify it, is part of the job, and it is what I remember most from this contract.

The situation

A training platform connecting health professionals, experts, content and events. Many people involved, very different expectations, and nobody between them. The doctor who held the medical authority, the CEO who made the calls, the remote developer I worked with in English, and the users had no common point of contact.

The direct consequence, and it is what links this case to the other two: what we published and what we developed was decided on impressions. Nobody had asked the therapists what they expected, and nobody looked at what the mailings actually brought in.

What I did

• Held the link between the users, the doctor who held the medical authority, management and the developer, remotely and in English: gathering, translating, prioritising, and passing on only what was properly scoped
• Organised the webinars end to end: preparation, registrations, live technical hosting, then putting the replay online on the platform and following up after the event
• Managed and issued the participants' certifications
• Implemented the premium training offer in the platform and organised its launch to the users who were already active
• Supported users day to day: solving their technical problems, showing them what they were not using, and talking to those who wanted to leave to understand why, which is the real work of support
• Asked the therapists themselves what they expected from the platform, instead of inferring it from what the team imagined. It is the simplest thing on this list, and nobody had done it
• Wrote around thirty newsletters on Mailchimp, one a week and one for each new webinar, to bring users back to the sessions, live or on replay, and to sell the training. Each contact carried a qualification score set by hand, which decided what they received
• Tracked what these mailings and the social media campaigns brought in, so that the choice of the next one rested on the previous ones rather than on the idea of the day
• Cleaned the database from about 2,000 rows down to 300 properly qualified ones: a smaller, true database is better than a large, false one, and a false database makes every measurement you take afterwards lie

What it is worth, and what it is not

It was an internship, and I did not revolutionise anything there. I had neither the mandate nor the seniority for that. What I did fits in one sentence: asking the people who used the tool, looking at what the mailings brought in, and making the database clean enough for those measurements to mean something. It is a small scope, and it is already the same reflex as in the two previous cases.

The result

More than 30 webinars coordinated, around thirty newsletters written, and more than 50 users supported individually, out of a community of about 90 professionals who were really active at the time. And a contribution to the launch of the premium offer.

The three numbers in this case do not count the same thing, and that is the kind of confusion that makes people doubt a file: 300 is the number of people who had bought at least once, what remained after cleaning the original 2,000 rows. 90 is the number who used the platform while I was there. 50 is the number I supported myself.