Approval of purchase requests delays deliveries

Why a purchase request becomes a bottleneck

In a manufacturing company, procurement rarely starts with one carefully completed document. A need may arise with a foreman, process engineer, engineer, operations department, or planner. Someone sends an email, someone writes in the corporate chat, and someone passes the information to a manager in person. As a result, the same task may appear in several channels, while some requests are never recorded at all.

At first glance, the problem looks like an ordinary approval delay. In practice, however, it affects the entire delivery cycle. While the request is being reviewed, the procurement specialist cannot properly request prices, the supplier does not receive the order, the warehouse does not know when to expect the material, and production has to revise its schedule. The more critical the item, the higher the cost of uncertainty.

Managing requests is especially difficult when a company has several sites, departments, and levels of responsibility. One category may require only a manager’s approval, while another may need a budget review, a technical assessment, confirmation from the security service, or a decision from several approvers. If the rules are not embedded in the process, each participant acts according to their own logic.

What usually slows down the progress of a request

• there is no single form with mandatory information about the item, quantity, deadline, and purpose;
• it is unclear who is responsible for the next step and where the request is currently located;
• approvers receive notifications through different channels and cannot see the context;
• changes to the request are not accompanied by a clear history;
• urgent needs are mixed with planned ones;
• managers learn about the risk of a delivery failure only after the problem has already occurred.

In such an environment, employees often compensate for the lack of transparency through manual control: they call colleagues, forward emails, keep local spreadsheets, and remind people about tasks in chats. This creates an impression of activity but does not establish a reproducible process. When an employee leaves, a manager changes, or the volume of procurement increases, the system quickly loses stability.

Consequences for production

Delayed approval does not always immediately lead to a line shutdown. Much more often, less noticeable symptoms appear first: urgent orders instead of planned ones, partial deliveries, repeated requests to suppliers, purchases on less favorable terms, and an accumulation of unfinished requests. These losses may be distributed across several departments and therefore remain without a single owner for a long time.

Production planning relies on the availability of materials, spare parts, tools, and services. If procurement information is outdated, the planner has to rely on assumptions. Some items are ordered too late, while others are kept in excessive stock. In both cases, the company loses control over its working capital resources.

There is also an organizational effect. Approvers begin to perceive requests as a stream of one-off favors, while the procurement department becomes a dispatch center that manually searches for missing information. At the same time, arguments about who delayed the process replace an analysis of where the process itself is poorly designed.

How the process changes in OpenBox

The “Request Management” solution in OpenBox helps move the procurement need from scattered channels into a single workspace. A request is created using a clear form, passes through defined stages, is directed to the responsible employees, and retains a history of actions. What matters is not automation itself, but the ability to define in advance the rules according to which the company wants to operate.

Instead of asking “who has the email now?”, users get specific information: who created the request, which department it belongs to, what is required, by when, which stage has been completed, who must take the next step, and what comments have already been added. This reduces the number of clarifications and helps quickly distinguish complete requests from those missing initial data.

Unified registration of needs

At the first stage, the company defines the set of fields. A request usually records the initiator, department, expense item or area, product or material specification, quantity, desired deadline, delivery location, justification, and additional documents. The set depends on the specifics of production: a technical item may require specifications, a drawing, or compatibility requirements, while a service may require technical specifications and the expected result.

Mandatory fields prevent users from submitting a request in which the procurement specialist would have to clarify basic information again. At the same time, the form should not be overloaded. If users see dozens of fields unrelated to their task, they start looking for workarounds. It is therefore better to divide the data into general and conditional fields: additional fields should appear only for certain categories or types of procurement.

Routing based on clear rules

After registration, a request can be routed based on the department, category, amount, urgency, or selected expense item. For example, technical materials may undergo a review by a relevant specialist, while requests involving financial restrictions may require additional budget approval. The route can be shorter for standard purchases and include an expert review for non-standard ones.

The route should not be defined once and then left without review. In manufacturing, the structure of departments changes, new categories emerge, and responsibilities are redistributed. Therefore, during implementation it is important to agree not only on the sequence of stages but also on the process owner responsible for keeping it up to date.

Monitoring deadlines and statuses

Each request receives a clear status, such as “created,” “under review,” “pending approval,” “sent to procurement,” “awaiting clarification,” “completed,” or “rejected.” The names should reflect actual actions rather than internal wording understood only by one department.

Employees can see the current stage without having to send inquiries to the procurement department. Responsible employees receive notifications about new tasks and changes. A manager can pay attention to requests that have remained at one step for too long, while a procurement specialist can focus on requests ready for further processing. This approach does not eliminate the need to make decisions, but it removes unnecessary waiting and manual searching.

Implementation scenario for a manufacturing company

It is more practical to start not by trying to automate all types of procurement at once, but with one manageable scenario. For example, a company might choose requests for production materials, spare parts, or repair services. At this stage, it is easier to identify the participants, collect real examples, and determine what data is actually needed to make a decision.

1. Review of the current process. The team records how a need arises today, where it is registered, who verifies the data, which approvals are mandatory, and at which stages returns most often occur.
2. Defining roles. The initiator, department manager, technical expert, financial approver, procurement specialist, and other participants are identified. For each role, the team describes not the position in general, but the specific action it performs in the request.
3. Designing the form. Fields are grouped by meaning, prompts and mandatory-field rules are added. It is decided separately which documents must be attached immediately and which are required only for certain types of need.
4. Configuring the route. Conditions for moving between stages, the approval sequence, rules for returning a request for revision, and actions in the event of rejection are established. This helps eliminate informal “parallel” approvals.
5. Piloting with a limited group. The new process is tested on real requests from one department or category. Users identify unclear fields, unnecessary steps, and situations that were not предусмотрены in the initial design.
6. Expansion and regulations. After adjustments, the scenario is extended to other departments. The regulations establish the rules for creating requests, response times, procedures for handling urgent requests, and responsibility for keeping the route up to date.

This approach prevents implementation from becoming an abstract IT project. The focus remains on a specific task: making the path of a need visible and predictable for everyone involved in procurement on a daily basis.

How to evaluate the result without formal reports

The effect of automation is best assessed through observable indicators rather than only by the number of requests created. Before launch, it is useful to record the initial state: how many channels are used, which data most often needs clarification, how many requests are returned for revision, where there is no responsible person, and which causes of delays occur regularly.

After moving to a unified process, the following indicators can be monitored:

• the share of requests created using the approved form;
• time spent at each stage;
• the number of returns caused by incomplete or contradictory data;
• the number of requests without an assigned responsible person;
• the share of urgent requests and the reasons for them;
• the number of overdue tasks broken down by departments and roles;
• the frequency of route changes and recurring exceptions.

These data are not an end in themselves. They help determine whether a problem is related to the form, authority, or demand planning. For example, a large number of returns may indicate not that initiators are inattentive, but that the requirements for describing an item are too vague. Regular urgent requests may point to a gap between the production plan and the procurement schedule.

What to consider before launch

Automation does not replace agreements between departments. If the company has not defined who is authorized to approve a material substitute, who is responsible for the technical assessment, and what qualifies as justified urgency, the software will merely transfer the ambiguity into a digital interface. Therefore, OpenBox configuration should begin with operating rules rather than a list of buttons.

It is also important to discuss exceptions in advance. Production needs special scenarios for emergency repairs, equipment downtime, safety requirements, and deliveries with strict deadlines. At the same time, “urgent” should not become a universal way to bypass the standard route. It is better to provide a separate request type, mandatory justification, and a subsequent review of the causes.

For users, a simple start is critical. The initiator should understand where to log in, which form to choose, and what will happen after submission. An approver needs a task queue with priorities and context. A procurement specialist needs filters and the ability to quickly see requests ready for processing. A manager needs an overview of workload and problem stages. When each person receives only relevant information, resistance to change decreases.

When to consider implementation

Automation is especially relevant if requests are regularly searched for in correspondence, managers cannot quickly obtain an up-to-date list of pending items, procurement specialists spend significant time clarifying initial data, and production learns about the risk of a delay too late. Another warning sign is the process’s dependence on a single coordinator who manually remembers whom to remind and about what.

OpenBox can become the foundation for a gradual transition to a manageable process: first unified registration, then routing and deadline control, followed by analytics of the causes of deviations and the development of scenarios. The specific configuration depends on the company’s structure, procurement categories, and existing approval rules.

If you want to understand exactly where time is being lost in your process, start by describing the current route and several real requests. During an OpenBox consultation, these scenarios can be reviewed, the required roles identified, and a reasonable scope for the first stage selected. A focused pilot will provide more value than trying to transfer all exceptions and informal arrangements into the system at once.