Out of the inbox: a knowledge platform for a pharma logistics provider

A pharma logistics provider Pharma logistics Pharma logistics is the term we use for storing, transporting and delivering medicinal products and other pharma-sector goods, such as promotional material and supplies for patients. Read in the glossary → has worked with us for more than 10 years, making it one of our longest-standing clients. For this client we have built, and keep developing, a platform that brings project knowledge, documents, time records and live data together in a searchable, linked knowledge base. The aim is simple: when key people are away or leave the company, the rest of the team still has the full picture.

The platform is not off-the-shelf software. It was built for the processes, projects and team of this one client, and it is now in its second generation.

Where is the knowledge when the person isn't?

Three typical situations show the problem.

• The holiday. A key account manager is away for two weeks. One of the logistics provider's customers asks where a project stands, and nobody else knows what was said in the latest emails.
• The departure. Someone leaves for another job. What they knew from experience but never wrote down goes with them, and project decisions made a year ago can no longer be traced.
• The audit. An auditor asks who decided what, and when. The answer sits in email threads that nobody can find any more.

We give selected project communication, such as support requests, minutes and agreements, a permanent place in the platform as structured knowledge entries, so that project knowledge does not disappear into mailboxes.

The difference in practice

When a key person is away, projects can carry on without them. A colleague standing in can answer questions within hours rather than days, because everything is collected in one place. The logistics provider's site managers answer their customers' questions directly, without having to ask us, the developers, because system availability, support hours used, open tasks, document history and project history are on one page.

That works because documents, time tracking, project descriptions for different audiences, automated reports, operational monitoring Monitoring Monitoring is the checking of IT components against defined thresholds, so that a notification or an alarm is triggered when a threshold is reached. Read in the glossary → and the chat assistant all share one set of projects, customers and permissions.

What changes for users

Very little. People keep using their usual email client and record their time as before. The platform needs no training, and the knowledge base grows from what they choose to send it.

The platform does not read anyone's mailbox. An email reaches it only when an authorised person deliberately forwards it to the platform's address or copies the address in (CC or BCC), adding a line on what to do with it if that is not obvious. Forwarding is a step, but there is nothing new to learn: nobody has to print, file or sort anything, and anyone who can send an email can do it. That human choice is the gate.

The platform also checks the sender. It accepts emails only from people set up as active users with incoming email enabled, and rejects all others. Because the platform collects its own mail, a forwarded email arrives at once, without anyone having to do anything in the application. The analysis by the AI AI Artificial intelligence (AI) covers methods that let a computer perform tasks which would require intelligence if a person did them. Read in the glossary → email agent, described below, starts only when a senior administrator (a user with the platform's highest role) triggers it with one click.

Anyone who wants to look something up can press Ctrl/Cmd+K for an instant search across projects, customers, tasks, knowledge entries and documents, depending on which of these features are enabled for them.

Project descriptions written from the running code

Project descriptions are based on an analysis of the software and configuration actually in use, so they reflect what runs today rather than outdated documentation. Our own analysis plugin, which runs in an AI coding assistant, reads a project's source code locally, taking the type of project into account. It then sends three things to the platform through its REST API API An API (application programming interface) is a defined set of functions and rules that lets one piece of software use the features or data of another system or service. Read in the glossary → : a description for each audience, the project's dependencies and its metadata.

There are eight audiences, among them project management, customer service, site management, pharma decision-makers, technical key account management and IT. Each gets a text pitched at its own level, in language that fits: decision-makers read about results, operational roles read about processes. On the project page, signed-in users see the standard description alongside the version written for their audience.

People stay involved at two points. After the code analysis, the plugin presents a reviewer with the features and modules it found and asks for corrections before any description is written. Once the descriptions are online, a reviewer reads them and has them corrected where needed. The model is explicitly forbidden to invent or guess: where abbreviations, business context or technical details are unclear, it has to ask.

When a project changes, a new analysis run regenerates every audience version, instead of the same information being updated by hand in several documents. Because they reflect the actual code, the descriptions are precise, and they save time and money.

Inside the plugin, a large AI model runs the workflow, and a smaller one handles all communication with the platform through a dedicated interface Interface An interface is the point at which two systems, programs or components meet and exchange data; the word also covers the user interface between a person and software. Read in the glossary → of our own, an MCP server MCP MCP, the Model Context Protocol, is an open protocol that connects applications built on large language models with external data sources and tools. Read in the glossary → with eight tools.

Can support hours be planned?

Projects can be billed under different models. Whichever applies, the platform counts every logged hour, and every invoice item can be traced back to specific time entries.

A coloured bar on each project, updated daily, shows how much of this month's allowance has been used. With it, users can answer a question such as how much support time a project has used this month in 10 seconds, without asking us.

The support analysis also forecasts three months ahead, using an exponentially weighted average, a trend and an uncertainty band. It needs at least four months of history, gives recent months more weight than older ones, and its chart gives early warning before the monthly allowance gets tight. The application is candid about its limits: it points out that the forecast is a statistical guide and does not account for seasonal fluctuations, project changes, team changes or new requirements.

Three further tools complete the picture:

• An allowance alert sends an email when a project reaches 75 per cent of its monthly allowance and another at 100 per cent. Each goes out at most once a month, straight after the daily import of time records.
• For administrators, a redistribution tool uses actual usage in completed months to suggest how the overall allowance could be shared out differently between projects, with the total unchanged.
• An annual comparison sets each project's hours against 12 times its monthly allowance and highlights overruns.

Where does work get stuck?

Tasks waiting on someone are tracked as well. One overview shows them by department, with the number of cases and the longest and average wait. It names no individuals and is meant as material for review meetings. It ensures nothing gets left behind and shows where workflows stall, so that processes can be improved. The waiting status on a task is only a flag for reporting; the real record is still kept in the chronological notes written by hand in the task description and the knowledge entries.

Confidentiality as a property of the data

There are four confidentiality levels, from unclassified to top secret. Access depends on two checks, and both must pass: the content's confidentiality level against the person's clearance, and whether the person belongs to the project or customer team.

Classified content is encrypted in the database, field by field, and people without clearance do not even see it listed. Only a senior administrator can lower a confidentiality level or release content to all signed-in users, and that holds for every route by which data can be changed. Even content released to all signed-in users stays behind the sign-in; nothing on the platform is public on the internet.

For confidential messages, there is a separate, encrypted messaging feature; it is not a way of sharing project information. A message is shared selectively via a link and protected by a password or sign-in; an expiry date and deletion after reading are optional.

Who decided what, and when?

This is the audit question, and the platform answers it from its own records. For every task, it shows when the task was created and every logged change since, with author and time, even after the task is closed. The project history shows in chronological order who changed what and when, and a shared case number links related tasks and knowledge entries into one case. Because the history is built from existing data and the change log, it also works retroactively. Classifications are logged too, and access, in the form of document downloads and logins, is recorded in a separate log. As everywhere on the platform, classified entries and those with restricted visibility stay hidden from anyone not entitled to see them.

Documents are versioned: every version is kept, along with who uploaded it and when. The download history is visible to the person who created the document and to senior administrators.

A word on regulation. Our client works in an environment shaped by Good Distribution Practice (GDP), the good-practice rules for distributing medicines. The platform itself is outside GxP scope, GxP being the umbrella term for pharma's good-practice rules, and we do not offer it as a validated system. Like the rest of our pharma IT, it is a specialist application that complements the established core systems. What an audit needs from it is traceability: the platform keeps decisions traceable, and in an audit it supplies the records the auditor asks for.

Reports that come to you

Rather than having to log in and look, the people responsible receive email reports on their projects, in the language and level of detail that suit them. There are four types: support time, tasks, allowance alert and AI monthly status. Reports are strictly opt-in: a master switch is off by default, each report is subscribed to separately, and a secure link lets the recipient unsubscribe from one report or pause them all. Each report contains only what the recipient is allowed to see in the user interface.

The AI monthly status follows a simple rule: the AI writes, it does not calculate. The model writes only the text (summary, assessment, recommendations and closing remarks); the template fills in every figure from the platform's data. For open tasks, the report shows how long they have been waiting and which department they are waiting on, but never the person.

AI under supervision

Of the platform's AI functions, two are kept apart on purpose: the email agent writes, and the chat assistant only reads.

The email agent writes, within limits

Once a senior administrator starts it, the email agent works with a fixed set of its own tools: it reads the relevant project with its tasks and knowledge entries, creates or updates tasks and knowledge entries, and assigns the email to a project or customer. It does not create documents and cannot delete anything, and the system logs every write action. Before creating a task, it has to check the existing ones and add to a similar task rather than create a duplicate, and it must not invent deadlines. It may take no more than 30 steps per email.

On confidentiality, the agent can only move in one direction. It raises an email's classification itself if the sender asks for this or if the email contains access credentials, contracts or personal data, and entries created from it inherit the level. Classified entries it creates are also restricted to the project team, because the agent cannot judge who else should see them. Lowering a level is left to a senior administrator.

If one of its tools fails, the error goes back to the model. The agent's reply also contains a list of the actions actually carried out, as logged by the system, so a claimed success that never happened shows up. We built it this way for a reason: an earlier agent whose tool errors were silently lost ended up reporting successes it had made up. For each email processed, the platform logs every tool call, the number of steps and the token usage.

The chat assistant only reads

The chat assistant answers questions in plain language from the organisation's own project data, not from the internet. It follows the same access rules as staff in the user interface, and on top of that its own access key only reaches content released to all signed-in users: anything confidential, secret or top secret simply does not exist for it. It answers quickly and links to the internal source.

The right model for each task

Model, reasoning effort and output budget can be set for each of the platform's AI endpoints in the admin back end: a small model for simple tasks, a mid-sized one for large prompts and the largest for demanding reasoning. Moving an endpoint to a new model generation is done there too, without any code change.

Access for other programs

Other programs reach the platform through its REST API: our analysis plugin, a process bot and AI agents. Compact output options make responses around 70 per cent smaller, leaving AI agents less to read, and the API hands out the next free case number without gaps, so agents neither guess a number nor assign one twice. For how we build agents like these, see our page on custom AI agents.

Why build rather than buy?

In our assessment, no standard product came close to meeting this combination of requirements.

• Standard time-tracking tools produce reports, but in our assessment they do not calculate forecasts, nor do they split hours by project and customer the way this platform does. And each user needs a paid licence of their own; without one, the only option is dashboards behind protected links that you send out yourself.
• Standard project management software does not analyse source code or write project descriptions from it.
• Large enterprise systems would be too expensive and too inflexible for the purpose, and would still not cover what the platform does.

Every additional product also brings overheads of its own. It has to be configured, and people have to be trained on it. It ties you to another vendor, and it means passing information to that vendor. Building custom software is our day-to-day business, and the result here does exactly what it is meant to do, in the way the logistics provider works. Our approach to that kind of work is set out on our page about custom software development.

Operation and quality assurance

We host the platform exclusively in Germany, with a specialist German hosting provider in a certified data centre in Frankfurt. It is covered by more than 1,400 automated tests, a number that grows with its functionality, plus strict static code analysis and end-to-end tests in the browser. Before any code leaves a developer's machine, an automated security check looks for access credentials left in the code by mistake and compares the packages in use against known security vulnerabilities, among other things.

Everything on the original roadmap has been delivered, and development continues as new needs arise.

What firms in other sectors can take from it

Because it was built for an environment shaped by GDP, the platform starts from a higher standard than many companies would need. For firms in other sectors, that is precisely what makes it interesting: its principles were designed for stricter demands than many of them face. Several of them carry over: knowledge goes in only when a person decides it should, access depends on both clearance and team visibility, in the monthly AI status report every figure comes from the platform's data and the model only writes the text, and project descriptions follow the code that actually runs.

Our other case studies show more of our work.