What we build
Six workflows, specified like parts rather than sold like packages
Each workflow below is written the way a quote should be: what goes in, what comes out, what a person has to approve, what it depends on, and what it explicitly does not cover. The exclusions are the important part.
Current offerConditional
Workflow
RFQ intake and routing
Quote requests arrive as plain email, forwarded threads, PDF attachments, spreadsheet templates, customer-portal notifications and phone calls written down afterwards. Someone has to read each one, work out what is being asked, decide who should handle it, and retype the details into a quoting system. That person becomes the bottleneck, and requests that arrive during a busy week can sit unread.
Specification
01
- Inputs
- A monitored mailbox or shared inbox, accessed with credentials the client owns
- Attachments already present in those messages, such as PDF or spreadsheet request forms
- Portal notification emails, where the portal does not offer an export or API
- An agreed list of customers, contacts and part numbers used for matching
- Workflow
- Read new messages from the monitored mailbox on a schedule or on delivery notification
- Classify each message: quote request, revision to an existing request, order, general enquiry, or something that needs a human to decide
- Extract the fields that are actually present, and record which fields are missing rather than guessing them
- Match the sender against known customers and contacts, and flag the record for review when the match is uncertain
- Detect probable duplicates and revisions by comparing part numbers, revision markers, quantities and the message thread
- Propose a route — an estimator, a queue or a review step — using rules agreed during scoping
- Present the result for human review, with the original message one click away
- Outputs
- A structured record per request with a stable reference, ready to be reviewed
- A written list of missing or conflicting details for the person who follows up
- A routing decision with the reason it was chosen
- An entry in a quoting system, spreadsheet or CRM where a supported write path exists
- An audit trail showing what arrived, what was extracted and who approved it
Control and dependencies
- Human approval
- A human confirms the extracted fields before anything is written into a system of record
- Uncertain customer matches are always reviewed by a person
- No reply is sent to the customer by the automation unless a person approves the text
- Depends on
- Mailbox access via a supported protocol, normally Microsoft 365 or Google Workspace
- A write path into the destination system: a documented API, an import format, or a database view
- Agreement on what a complete request looks like for this business
- Reference data for customers, contacts and parts that is accurate enough to match against
- Exceptions
- Requests where required fields are missing go to a review queue with the gaps listed
- Conflicting details, such as a quantity in the email that disagrees with the attachment, are surfaced side by side rather than resolved silently
- Messages that cannot be classified with confidence are routed to a person, not assigned a guess
- Failures are recorded in an error queue that can be retried without creating duplicate records
Delivered, and not delivered
- Deliverables
- The running integration, in accounts the client owns
- Written configuration and runbook documentation
- The classification and routing rules in readable form, not buried in code
- A handover session covering how to change rules and how to interpret the error queue
- Not included
- Reading dimensions, tolerances or geometry from technical drawings
- Calculating prices, margins or lead times
- Sending quotes or customer-facing commitments without human approval
- Replacing the quoting or ERP system
Workflow
Quote follow-up with human approval
Quotes go out and then compete for attention with the next urgent request. Follow-up depends on whoever remembers, so some customers are chased twice and others are never chased at all. There is usually no single place to see which open quotes are ageing and which are worth a phone call.
Specification
02
- Inputs
- A list of sent quotes with their date, value where available, customer and owner
- Quote status from the quoting system, an export, or a maintained spreadsheet
- An agreed follow-up schedule and the conditions that should stop it
- Message templates written and approved by the client
- Workflow
- Track open quotes and their age from the agreed source of truth
- Apply the follow-up schedule, skipping quotes that are already won, lost, on hold or under negotiation
- Draft the follow-up message from an approved template, filled with the quote details
- Place the draft in front of the owner for approval, editing or cancellation
- Record what was sent, when and by whom, and stop the sequence when the customer replies
- Outputs
- A queue of drafted follow-ups awaiting approval
- A view of open quotes by age and owner
- A log of follow-up activity per quote
- Notification when a quote passes an agreed age threshold without action
Control and dependencies
- Human approval
- Every customer-facing message is approved by a named person before sending
- Templates are approved once in writing, and changes to them are approved again
- Automatic sending without approval is not offered as a default configuration
- Depends on
- A reliable signal for quote status; if status only exists in one person’s head, that has to be fixed first
- A sending identity the client controls, with correct SPF, DKIM and DMARC records
- Agreement on how a reply is detected so sequences stop promptly
- Exceptions
- Quotes with no owner or no status are held for review rather than chased
- A customer reply, out-of-office bounce or hard bounce stops the sequence and is flagged
- Anything involving pricing changes, negotiations or complaints is routed to a person immediately
Delivered, and not delivered
- Deliverables
- The follow-up workflow with the approval step in place
- The approved templates, stored where the client can edit them
- Documentation of the schedule, stop conditions and escalation rules
- Not included
- Deciding or changing prices
- Negotiating on the client’s behalf
- Bulk marketing email or list building
- Sending anything to a contact who has asked not to be contacted
Workflow
Order entry and system-to-system data movement
A purchase order arrives, and its contents are typed into the ERP, copied into a spreadsheet for scheduling, and repeated in an email to production. Each retype is a chance to transpose a quantity or miss a revision, and each system holds a slightly different version of the truth.
Specification
03
- Inputs
- Purchase orders as email attachments, portal downloads or structured feeds
- The accepted quote or price agreement the order relates to, where one exists
- Field mappings agreed between the source document and the destination system
- Validation rules: what must be present, and what must match before an order is created
- Workflow
- Collect the order document and record it against a stable reference
- Extract the order header and line items, keeping the source document attached to the record
- Validate against the referenced quote and against the client’s own rules for part numbers, revisions, quantities and dates
- Present differences between the order and the quote for a person to accept or reject
- Write the approved order into the destination system using an idempotency key, so a retry cannot create a second order
- Confirm the write succeeded and reconcile what was created against what was approved
- Outputs
- An order record in the destination system, created once
- A difference report between order and quote where they disagree
- A confirmation record linking source document, approval and created record
- An error queue entry when a write fails, with enough detail to retry safely
Control and dependencies
- Human approval
- A person accepts any mismatch between order and quote before the order is created
- Price, quantity and delivery-date changes are always reviewed by a person
- First deployment runs in shadow mode: the workflow proposes, a person still enters, and the outputs are compared
- Depends on
- A supported write path into the destination system, or an import route it accepts
- Documented required fields; many ERP systems reject partial records in ways only revealed by testing
- A non-production environment or a reversible test approach, so failed writes are not created against live data
- Exceptions
- Orders referencing an unknown part, customer or quote are held for review
- Duplicate purchase-order numbers are detected and held rather than written twice
- Partial failures are rolled back or quarantined, never left half-written silently
Delivered, and not delivered
- Deliverables
- The integration, with idempotent writes and a documented error queue
- Field mapping documentation, including the fields deliberately left out
- A rollback and re-run procedure that a non-developer can follow
- Shadow-mode comparison results from before go-live
- Not included
- Interpreting engineering drawings or specifications attached to an order
- Deciding whether an order should be accepted commercially
- Scheduling, capacity planning or shop-floor decisions
- Changing prices or terms
Workflow
CRM and ERP workflow connections
The CRM holds the customer conversation and the ERP holds the transaction, so the same information is maintained twice. Someone copies quote and order details between them, and the two drift apart. Broad "sync everything" projects tend to fail because nobody agrees which system wins.
Specification
05
- Inputs
- A single named workflow to connect, with a defined direction of travel
- A decision about which system is authoritative for each field
- Access to both systems with scoped credentials
- The list of records in scope, and the records deliberately out of scope
- Workflow
- Define the authoritative system per field in writing before any code is written
- Read changes from the source using an API, a read-only view or a scheduled export
- Transform records to the destination’s expected shape, validating before sending
- Write with idempotency keys so repeated delivery does not create duplicates
- Reconcile on a schedule: compare both sides and report differences rather than overwriting quietly
- Outputs
- A one-directional or explicitly bidirectional connection for the named workflow
- A reconciliation report showing records that disagree
- An error queue with retry, and alerting when the queue is not empty
- Documentation of every mapped field and every field left unmapped
Control and dependencies
- Human approval
- Field authority decisions are approved in writing by the client
- Bidirectional writes are only built where a conflict rule has been agreed
- Bulk changes are reviewed before the first production run
- Depends on
- A usable integration path on both sides. Not every ERP exposes one, and this is checked during assessment
- Rate limits and API quotas that can accommodate the expected volume
- A stable record identifier on both sides that can be matched reliably
- Exceptions
- Conflicting edits on both sides are reported for a human decision, never resolved by last-write-wins unless explicitly agreed
- Records failing validation stay in the error queue with the reason
- Schema changes in either system stop the workflow and raise an alert rather than writing incorrect data
Delivered, and not delivered
- Deliverables
- The integration, running in client-owned accounts
- A field-authority and mapping document
- Reconciliation reporting and an alerting configuration
- Runbook covering common failures and how to recover from them
- Not included
- General-purpose data synchronisation across all objects
- Data warehousing or business-intelligence reporting
- ERP customisation, configuration consulting or licence changes
- Migrating from one system to another
Workflow
Workflow visibility and exception handling
Automation that works invisibly is fine until the day it stops. Without a queue and a report, failures are discovered by a customer asking why nobody replied. Even before automation, most teams cannot see how many quotes are open, how old they are, or which requests were dropped.
Specification
06
- Inputs
- Events and records produced by the workflows already in place
- Agreed thresholds: when something is late, stalled or unattended
- A defined recipient for each type of exception
- Workflow
- Record a state transition for every item as it moves through the workflow
- Detect items that breach an agreed threshold, such as an unactioned request or an ageing quote
- Route each exception to the person responsible, with the context needed to act
- Retry transient failures with backoff, and stop retrying permanent ones
- Report on volume, ageing and exception counts on an agreed cadence
- Outputs
- A queue of open items with age and owner
- An error queue with the reason for each failure and a safe retry action
- A recurring summary report
- An audit trail per item, from arrival to resolution
Control and dependencies
- Human approval
- Retry actions that touch a system of record require a person unless the operation is provably idempotent
- Threshold and alert-recipient changes are approved by the client
- Depends on
- Workflows instrumented to emit state transitions, which is designed in from the start
- A destination for reports and alerts the team already reads — normally email or an existing chat channel
- Exceptions
- An empty report is still sent, so silence is never mistaken for success
- Repeated failures of the same type are grouped instead of flooding an inbox
- Alerting failures themselves are surfaced on the next run
Delivered, and not delivered
- Deliverables
- Queue and reporting views
- Alert configuration and escalation documentation
- A runbook for each known failure mode
- Not included
- A general business-intelligence platform or executive dashboard suite
- Around-the-clock monitoring or an on-call service commitment
- Storing operational data longer than the client requires
Feasibility
How a system is actually integrated with
No assumption is made that an ERP has a usable API. Many do not, and several that do restrict it to a licence tier the client does not hold. These are the paths, in the order they are preferred.
| Path | Preference | What it is | Conditions |
|---|---|---|---|
| Supported API | Preferred | A documented, vendor-supported interface with authentication, versioning and defined error responses. Changes are announced, and behaviour can be tested. | Requires the vendor to offer one on the client’s licence tier, with quotas that fit the expected volume. |
| Read-only database view | Workable | A restricted view over the system’s own database, used for reading only. Reliable for reporting and for detecting change; it must never be used to write. | Requires vendor permission, a supported hosting arrangement, and acceptance that internal schemas can change between releases. |
| Scheduled export and import | Workable | The system produces or accepts files on a schedule. Unglamorous and durable: batch boundaries are explicit, and a failed batch can be re-run. | Adds latency measured in the schedule interval. Requires a stable file format and agreed handling of partial or duplicate batches. |
| File transfer | Workable | Files exchanged over SFTP or a monitored folder, with checksums and a processed-file archive so a batch cannot be consumed twice. | Requires agreed naming, encoding and retention rules, plus somewhere to quarantine files that fail validation. |
| Controlled UI automation | Last resort | Driving the application’s own interface the way a person would. It is the most fragile option available: a layout change, a slow page or an unexpected dialog can break it, and it can be difficult to prove what it did. | Only considered when no other path exists, only for narrow and reversible steps, never for silent writes, and only where the vendor’s terms permit it. If UI automation is the only way to complete a critical write, the honest recommendation is usually not to automate that step. |
Request a workflow review
Not sure which of these fits?
That is what the review is for. Describe the workflow that costs the most time, and the recap will name the one or two options worth investigating — or say that none of them is worth the money.
30-minute review. You receive a concise written recap. No obligation.
Engagement capacity is intentionally limited so discovery, implementation and handover remain founder-led.