David Dealsworth — Purchasing Manager

• Name: David Dealsworth
• Quote: “If the queue is empty by noon, it’s been a good day.”

Professional Background

• Job Role/Title: Purchasing Manager (end-user, order executor). Also called Procurement Coordinator. In small operations, this is the same person as the Inventory Manager. In medium to large operations, they are distinct roles: the Inventory Manager decides what needs to be ordered (by managing cards and reorder points), and the Purchasing Manager decides how and when to place those orders.
• Company Information: Small to mid-size manufacturing or healthcare supply operation. The Purchasing Manager sits at the boundary between internal operations and external suppliers. They have contacts at multiple vendors and may interact with the finance department for PO approvals.
• Responsibilities: Executing purchase orders across four fulfillment workflows: Online (supplier portal checkout), In-Store (physical pickup with mobile recording), Email/Purchase Order (pre-filled email drafts or generated PDF POs), and RFQ (Request for Quote for items requiring supplier pricing before ordering). Tracks order status through the card lifecycle states: AVAILABLE -> REQUESTED -> INPROCESS -> FULFILLING -> DELIVERED. Manages supplier relationships and ensures order records are accurate. May handle purchasing themselves or coordinate with the Inventory Manager depending on operation size. Success is measured by order cycle time, supplier on-time delivery rates, and order accuracy.
• Career Path: May come from a procurement or operations background. More comfortable with purchasing workflows and vendor portals than with physical shop floor operations. Familiar with web-based ordering portals (Amazon Business, Grainger, supplier-specific procurement systems).

Goals and Motivations

• Professional Goals:
  • Execute purchase orders efficiently. Get items from “needs ordering” to “supplier has the PO” as fast as possible, with an accurate record of what was ordered, from whom, at what price.
  • The Order Queue is empty by noon. Every item that workers scanned in the previous 24 hours has been ordered.
  • Supplier confirmations are on file. Items in transit are visible so receiving can be scheduled.
  • Preserved order details: supplier, part numbers, pricing, and lead times stay attached to the item through the card system.
• Motivations:
  • A single queue grouped by supplier, with all ordering details attached, replacing the email chaos of manual purchasing. Without a system, the Purchasing Manager receives “we’re out of X” messages by phone, Slack, text, and sticky note.
  • Eliminating duplicate orders and items falling through the cracks. Trackable closed-loop systems mean every order has a paper trail from scan to receipt.
  • Fast lookup when a supplier calls about a price change or backorder, to see which items are affected immediately.
  • Observable actions: management can see what is being ordered without asking.

Challenges and Pain Points

• Obstacles:
  • Items missing supplier URLs: the “Start order” button is disabled with a tooltip “This item is missing a URL and cannot be ordered,” forcing manual ordering (phone, email) outside the system.
  • Items without supplier configuration require editing the item record (adding Primary Supplier, SKU, supplier URL, Order Method) before the order can be placed, adding friction to the morning processing flow.
  • Distinguishing between “Ready to order” (REQUESTED state) and “Recent orders” (INPROCESS state) tabs requires understanding the card state model. In streamlined workflows, some states (READY, FULFILLING) are often skipped.
  • Phone-only suppliers cannot be integrated into the digital workflow; the Purchasing Manager must manually advance card states after placing verbal orders.
  • Items bypassing the card system (“ordered without a card”) create blind spots: broken kanban loops, lost inventory visibility, noisy reorder triggers, and vanished accountability. This is the scenario the “Never Order Without a Card” rule prevents.
• Fears/Objections:
  • An item falls through the cracks because it was not visible in the queue (data or state mismatch).
  • Supplier backorders or price changes that are not reflected in the system, leading to stale information.
  • Tension with the Inventory Manager: if reorder points are set too high, the queue fills with items that do not actually need ordering yet. If supplier URLs are missing, the Purchasing Manager cannot use the one-click order flow.

Behavioral & User Environment

• Typical Day/Workflow:
  1. 8:45am: Open Order Queue. Review items grouped by supplier. Start with suppliers that have configured URLs (one-click to open supplier portal in new tab — the Online fulfillment workflow).
  2. 9:00am-10:30am: Work through the queue supplier by supplier. Open portal, place order, return to Arda, advance card states from REQUESTED to INPROCESS. Move physical cards from “To Order” bin to “Ordered” bin. For Email/PO suppliers: use Arda’s pre-filled email draft or generate a PDF Purchase Order and send to the vendor. For RFQ items: generate a Request for Quote, send to supplier(s), and convert to PO once the quote is accepted.
  3. Handle problem items: suppliers without URLs (edit item to add Primary Supplier and supplier URL), phone-only vendors (call, then manually advance state), items with missing data.
  4. 2:30pm: Respond to supplier calls about backorders or delivery changes. Update card notes, notify the Inventory Manager about delays so they can check physical supply and potentially emergency-order from a secondary vendor.
  5. End of day: Quick check that the queue is clear. Any remaining items are flagged for tomorrow.
• Session Characteristics: One longer working session per morning (20-45 minutes) to process the day’s orders, then shorter return visits (2-5 minutes) to check on in-progress items. May have Order Queue open in a pinned tab.
• Technology Use: Office desktop or laptop, dedicated workstation (not shared). Moderate to high technical proficiency. Comfortable with web interfaces and multi-tab workflows. Browser-based supplier portals are a core part of the workflow. Will try to use keyboard shortcuts. Position the scanner within reach for occasional ad-hoc scans, though the USB scanner is primarily the Inventory Manager’s and Receiving Clerk’s tool.
• Information Sources: Supplier portals, internal order history in Arda, communication with the Inventory Manager about reorder priorities. Arda help center articles on placing orders and card states.
• Decision-Making Process: Acts on signals created by the Inventory Manager’s card setup. Makes independent decisions about order timing and supplier selection. Coordinates with finance for large POs. Communicates delays and issues to the Inventory Manager.

Personality & Work Style

• Personality Traits: Efficient, process-driven, comfortable with multi-system workflows, focused on throughput and clearing the queue. Values shared standards: everyone follows the same process.
• Communication Preferences: Prefers in-app status indicators and queue-based workflows. Communicates with suppliers via their portals, email, or phone. Coordinates with the Inventory Manager about order status and data quality issues. Appreciates when the Inventory Manager enforces card discipline, because every order that bypasses the card creates work and risk downstream.

Relationship to Other Personas

• Irene (Inventory Manager): Irene’s card setup and reorder points create David’s work queue. Data quality issues (missing supplier URLs, wrong SKUs) flow directly from Irene’s item records to David’s morning friction. They coordinate on delays and emergency reorders.
• Alan (Account Admin): Alan’s data quality during onboarding directly affects David’s workflow. Every missing supplier URL creates a disabled “Start order” button in David’s queue.
• Keisha (Receiving Clerk): Keisha closes the orders David placed. David needs to know when items arrive so he can track supplier on-time delivery and handle backorder communications.
• Owen (Business Principal): In small operations, Owen is David. In larger ones, David executes Owen’s purchasing strategy. Owen cares about total spend; David cares about queue throughput.