“Automate approvals” does not define where a process starts, what needs approval or what happens after an amendment. To assess delivery, the provider needs one existing process with its inputs and exceptions.
A professional diagram is unnecessary. A file the responsible employee can read and correct is enough to begin. Identify unknowns explicitly. Finding missing measurements or decisions is better than turning guesses into specifications and prices.
Choose boundaries before choosing a tool
A fictional company approves bilingual marketing material before publication. The process starts with a complete editorial version, passes content, translation and brand review, and ends in approval or a revision request. Completion here is a decision on a specific version, not automatic publication to every channel.
Define phase-one inclusions and exclusions. Does automation route reviews, notify people and retain decisions, or also integrate publishing? That difference affects access, tests and accountability. It cannot be inferred from “automation” alone.
A six-part preparation pack
- Start and finish: The initiating event and the result considered complete.
- Steps and roles: Receivers, workers, decision-makers and handoffs.
- Inputs and systems: Fields, files, sources and available access.
- Volumes and rhythm: Frequency, file sizes, peaks and measured versus estimated values.
- Exceptions and intervention: Missing information, rejection, cancellation, changes, absence and unavailable systems.
- Baseline and acceptance: Pre-trial measurements and evidence that the delivered scope works.
Attach a small representative sample for each part. For marketing material, this could be a test version, review notes and a revision case rather than the entire company archive. Share enough to explain the work without unnecessary sensitive files or passwords.
Map actual behavior before proposed changes
Ask staff about the real route, including follow-up messages, resent versions and verbal approvals. Record differences between written procedures and the observed sample rather than draw an ideal process nobody uses.
Microsoft's process-management guidance emphasizes understanding the current state before designing and testing change. For procurement, distinguish reality from the rule you want to introduce. A duplicate step or missing owner may need correction before automating its notifications.
A case sheet exposing incomplete descriptions
| Example case | Decision to document |
|---|---|
| Material arrives without required translation | Return it or hold it? Who is notified? |
| The version changes after approval | Is approval repeated, and who defines review scope? |
| The approver is absent | Who substitutes, within what authority, and how is the decision recorded? |
| The file system stops responding | Where does state remain, and how does work resume without losing notes? |
| A request is cancelled during review | What stops, and who checks actions already started? |
Not every answer is technical. Supervisor review may be appropriate when ownership is known, status is visible and automation does not continue as though the decision were settled. Exceptions should not disappear from a proposal only to emerge on the first working day.
Volumes need an identifiable source
Use available records to collect cases over a representative period, file sizes, revision frequency and peaks. Separate measured values from staff estimates and identify unusual periods. One observation should not become a fixed monthly average without supporting data.
Distinguish working time from waiting between roles. Material may wait a long time despite a short review. Automating its delivery cannot guarantee reduced waiting if ownership and availability remain unresolved.
Define what the solution may read or change
List required systems and operations your team can authorize. An employee login does not establish an available official integration or justify exposing everything in that account. Identify missing prerequisites, licences and interfaces before approving integration scope.
Reading a review copy differs from changing the original or publishing it. Separate permissions and approval ownership. If AI processes text, define its task and review boundaries rather than assume every administrative step requires AI.
A small baseline instead of general promises
Choose problem-related measures: cases returned for missing inputs, requests waiting for approval or comments lost between versions. Microsoft's value-measurement guidance uses quantitative and qualitative evidence rather than relying only on unproven time-saving estimates.
Agree before-and-after samples, comparison definitions and limits, plus review ownership for interventions. A marketing time-reduction percentage is not a guaranteed project target. Clear responsibilities or version traceability may provide value even if review time itself changes little.
Send an answerable proposal request
Attach the pack and request scope, assumptions, exceptions, recurring costs and handover outputs. Identify who monitors the workflow, stops or intervenes during a problem and receives the rules after implementation.
Use the guide to choosing a suitable automation process before preparation, and the integration quote inputs when several systems are involved. Start a request for business process automation with the process file and sample so price discussion relates to understood work.
Method sources
Microsoft's process-management guidance and solution-value measurement guidance were opened on 3 November 2026. The pack, example and case sheet are original editorial proposals, not a tool recommendation or savings guarantee. The text was prepared with AI assistance and review of its content and sources.
