Discuss your projectReplace the shared spreadsheet, the approval email thread, and the admin console nobody was given. Every request becomes a record with an owner, a history, and reports that build themselves.
Illustration of an internal purchasing tool built by Baybloom: requests as records with owners and budget lines, approvals recorded, and the weekly report built from the records.
Operations, finance, and admin leaders whose team runs part of the business from a spreadsheet shared by too many people, an inbox that doubles as a queue, or a vendor product’s admin screen that does not fit. Usually the process is sound; the tool is the problem.
The workflow
The steps we see most often in this kind of operation.
Features
Capture each request with required fields, attachments, and validation, so the team starts work with complete information instead of chasing details by email.
Assigns each record to the right person or team based on type, value, department, or location, and reassigns it when someone is away.
Alerts owners and approvers by email or chat when something needs their action, and escalates items that sit unanswered past the limits you set.
Loads existing spreadsheet data into the tool at launch and lets finance export clean records whenever an auditor or accountant asks for them.
Lets each person filter records by status, owner, or date and save the views they use, replacing the color-coded tabs of the old spreadsheet.
Shows who changed each field, from what, to what, and when, so questions about a decision are answered from the record itself.
Your first release
How the work runs
We start with the people doing the work and the systems around it, then write down the first release: what it includes, what it leaves for later, the integration decisions, and the acceptance criteria. Nothing is built until that scope is agreed.
We build in releases you can review as the work takes shape, using realistic data. Every release carries tests, a security review, and documentation. Integrations are tested against real records, with exceptions visible.
Your team receives the documentation, the runbooks, and the training to run the system, and we stay on for continued engineering when you want it.
Scope and price
Every project is priced from a written scope. These are the factors that move it most.
One workflow with a single team is contained, and each additional process, department, or record type adds its own fields, rules, and screens.
Simple edit and view rights are straightforward, while approval thresholds by amount, department, or location need a rules design and careful testing.
Accumulated inconsistent entries, merged cells, and free-text fields must be cleaned and mapped before the existing records can load into the tool.
Posting to accounting, reading from the CRM, and single sign-on each add an integration with its own mapping, error handling, and testing.
Distributor purchasing team
At many distributors, purchase requests arrive from several departments by email, get typed into a shared spreadsheet, and are approved by reply-all. A first release turns each request into a record with a requester, a budget line, an approver, and a stage. Approvers act in the tool under the thresholds finance sets, and the spend report builds from the records instead of from copied cells. Buyers stop asking where a request stands. A later phase often posts approved orders to QuickBooks or NetSuite, so accounting sees the commitment without re-keying it.
Questions
What buyers ask before a project like this starts.
For a simple form and list, a low-code tool is often the better choice, and we will point you to one. When the workflow has rules, roles, integrations, and history that matter, a custom tool is easier to maintain and does not carry a per-seat license.
The spreadsheet stays until the first release is in daily use and the reports match. Then it becomes read-only, and nothing is deleted without sign-off.
Yes. Posting approved records to accounting is a common part of the first or second release, built against real records with exceptions visible.
Your team administers it through the admin view, using the documentation and training from the handover. Continued engineering from us is optional.
The tool is designed around the steps the team already follows, so most of the learning is where to click. A walkthrough for each role, a written guide, and an admin who can answer questions usually cover adoption for an internal team.
Yes. Fields and records can be restricted by role, sensitive changes are logged, and data is encrypted in storage and in transit. Access rules are enforced on the server, so each person sees only what their role permits, including in exports and reports.
Common adjustments such as picklist values, approval thresholds, users, and notification recipients are managed from the admin view by your team. Changes to the underlying rules, new stages, or new integrations are engineering work, scoped and tested before release.