project X, name under NDA

A system of forty-five sections and one part we had to build separately

Forty-five sections instead of scattered spreadsheets and chat threads. At the core of the system sits the assembly of a personal plan that a specialist used to do by hand.

What changed

before

Orders, subscriptions, stock, purchasing and money lived in different places. They came together only in the heads of a few people, and every report was put together by hand.

after

One system with separated rights: every role has its own section and its own access. Reports assemble themselves, and the full history of changes is kept.

Clients, subscriptions and pauses. The whole history with a client in one place, breaks and refunds included.
Stock, purchasing and production. What to order, what to prepare and in what order, with printable sheets for the people working with their hands.
Money. Plans, invoices and refunds reconciled with the payment system, without balancing anything by hand at the end of the month.
Nine roles with different rights. Everyone sees their own part, and every change is written to the log.

Where it got hard

The remaining sections are covered by ordinary means. One part had to be built separately: the assembly of the personal plan. Below are three forks and what each would have cost had we taken the wrong side.

Hard bans cannot be left inside the request

cost of getting it wronga broken ban means harm to a person on the other side, not a spoiled impression

A miss on a preference is unpleasant, and people live through it. A broken hard ban is an event of another weight, and it will not be support who deals with it.

So the bans were moved outside, into a reference list. Code checks them both before assembly and after it, and an option that breaks even one of them never leaves the system at all.

The first answer is almost never good enough

cost of getting it wronga person fixes the output by hand, and the automation saves nothing

Free assembly gives duplicates within a single day, a bias towards one component across a whole week, and empty slots where there should be none.

We did not try to fix this by rewording the request. After assembly comes a check against rules written in code: if something does not add up, the request goes back with a note on what exactly. Up to five rounds, after which the option counts as unassembled and is handed to a person.

Variety rests on history, not on luck

cost of getting it wrongthe repetition is spotted by the person on the other side, and spotted before us

A person notices the same thing coming back week after week. The system will not notice it on its own: it does not remember the previous time.

We keep the history ourselves. What was recent is excluded, what was earlier is lowered in priority, and the frequency of any one component has a ceiling written as a rule.

How we checked that it does not lie

The rules live in code, not in the wording of the request. They can be read, discussed with the client and changed, without guessing how the system will respond.
Every assembly is kept in full. You can see what was asked, what came back, which rules did not pass and how many rounds it took.
Nothing doubtful is slipped in silently. If an option has not come together in five rounds, it is not handed over as finished but goes to a person.

Have a task like this?

We will look at what carries over to your process, and show you a working prototype before you pay.

Discuss your task