Example deliverable
Sales call preparation using buyer-provided context
Maya’s purchase-approval review
Preparation boundary
This brief prepares Cedar’s consultant for a process review with Maya Chen, Northline’s fictional finance director. It is separate from Colony Spark’s 15-minute strategy call. Maya supplied a note and a redacted purchase request. No system access or configuration change has taken place.
The decision Maya wants help with
“Can we move purchase approvals into NetSuite without rebuilding everything?”
The private process details below come from the fictional buyer inputs. They do not come from public research.
- System
- Maya confirms that Northline uses NetSuite.
- Structure
- Three subsidiaries share a purchasing team, according to her booking note.
- Current process
- Requests and manager approvals happen in email. Finance then creates the purchase order.
- Approval rule
- Maya says requests above $10,000 need finance-director approval. The exact basis needs checking.
- Missing information
- Subsidiary and project are added after the manager’s approval in the sample she supplied.
The process to review
-
Purchase request
The requester sends an email.
Check: Subsidiary and project are not consistently included.
-
Manager approval
The manager replies in the email thread.
Check: Confirm whether approval depends on entity, amount, or project.
-
Finance check
Finance adds missing details.
Check: Identify requests that need to go back for clarification or approval.
-
Purchase order
Finance enters the order in NetSuite.
Check: Inspect the existing approval configuration before proposing a new workflow.
What still needs verifying
Confirm that the sample represents the normal process, inspect the existing approval rules, and identify who can test a change. Separate a process decision from a configuration recommendation.
How to open the conversation
“Maya, you want to move approvals into NetSuite while keeping the parts that already work. Can we start with the purchase request you sent and follow where each decision happens?”
Questions in order
- Where are the subsidiary and project added to a purchase request today?
- Who can approve for each subsidiary, and what happens when that person is away?
- How is the $10,000 limit applied: per request, per purchase order, or another basis?
- Which approval features, workflows, and customizations are currently enabled?
- Who owns the process and who can test a change before it goes live?
- What evidence would show that the revised process is working?
Have these ready
The supplied purchase request, the current approval policy, screenshots of the enabled rules, and the name of the process owner. Confirm who can inspect the configuration and test changes before offering an implementation scope.
Technical reference
This is a real technical reference supplied with the fictional example. It describes approval-rule setup. It does not show which features Northline has installed or how they are configured.
Illustrative pre-call note
This draft uses only the fictional buyer inputs above. Cedar would review and approve it before sending.
Subject: Northline’s approval process for Thursday
Maya,
The purchase request you shared is approved by a manager before anyone adds the subsidiary and project. Finance then has to fill those gaps before it can create the purchase order in NetSuite.
I mapped that handoff below. For Thursday, we need to confirm who can approve for each subsidiary and how your $10,000 approval limit is applied.
Please bring one recent approved request and a screenshot of the approval rules currently enabled in NetSuite, with supplier and employee details redacted.
We will compare the rules with the process your team follows and identify what the existing setup can handle, what needs configuration, and what needs a separate technical check.
Alex Cedar ERP
A useful outcome
Agree on one approval path to inspect, the missing information, and who can validate a proposed change in a test environment.
Confirm the existing features and customizations before estimating the work. The call should end with an inspection path and a named validator, not an unsupported technical promise.