Who this is for. AP Helpdesk Analysts and Managers. See the Roles and Access.
An AP Helpdesk Agent Co-worker triages vendor email, answers it, and routes tasks that need human intervention to the correct person. This article follows one message from arrival to task, which is what you retrace when the agent did something you did not expect.
AP Helpdesk is a function selected on an instance of SmartVendor, not an agent in its own right. For where it sits among the other agents, see Agent Co-worker Overview.
The two functions an instance can hold
Both are functions you select on an instance rather than separate agents.
Table 1. Functions
Function |
Does |
|---|---|
AP Invoices |
Extract invoice header and line fields, run purchase order and supplier contract matching, and post approved invoices to the system of record. |
AP Helpdesk |
Triage vendor email, answer it, and route tasks that need human intervention to the correct person. |
One instance can hold both. Each selected function gets its own tab of capability settings, and the two are configured independently. Turning on AP Invoices does not change anything about how AP Helpdesk replies.
What AP Helpdesk produces
Tasks in the AP Helpdesk queue, each carrying the agent’s reading of the email: an Intelligent Summary, a detected category, a matched vendor and, where the rules call for one, a drafted reply for review.
The draft is the part worth understanding. A drafted reply means the agent was confident enough to compose but not permitted to send; a sent reply means it was both. The difference is the autonomy level, not the quality of the draft.
Four processing stages
Table 2. Stages shown on a task
# |
Stage |
What it produces |
|---|---|---|
1 |
Triage |
A sender classification and a first read of the message. |
2 |
Email Category Detection |
The category that says what the message is about. |
3 |
SOR |
Lookups against the system of record: the vendor, the bills, the payments. |
4 |
Draft Response |
A reply, where the rules called for one. |
A completed stage shows a check mark; the stage in progress shows its number. A message that stopped early stopped for a reason the drawer will name.
What decides the outcome
Three pieces of configuration meet on every message.
Table 3. What decides the outcome, in order
# |
Decision |
Set in |
What it drives |
|---|---|---|---|
1 |
Sender type |
Contact Management |
Whether the agent may act for this sender at all, and what it may access. External, Internal, System or Unknown. |
2 |
Email category |
Email Categories |
What the message is about. |
3 |
Processing rules |
Processing Rules |
What happens next, given the sender and the category. |
4 |
Action |
The actions on each rule |
The concrete thing the agent does. |
A rule is addressed by both the category and the sender type, so the same request from a vendor and from a colleague can be handled differently. A rule therefore addresses a sender type and a category together.
Sender-aware rules are not the only ones running. Sender-agnostic rules from the Intelligence Layer run alongside and apply to every sender, so a behavior with no matching rule in the wizard may be coming from the rulebook instead.
For managers
This section is for AP Helpdesk Managers and ProcureToPay Managers, the roles that own the rules and thresholds the agent works by. ProcureToPay Managers carry the same coverage across AP Invoices as well. Reading the configuration is not the same as changing it: only a Super Admin can edit it, on the Define capabilities step.
Actions available to a rule
Add label, Add note, Add task, Prepare reply, Send reply, Transfer invoice, Transfer credit memo, Prepare write to SOR, Write to SOR, and Route to non-business folder.
Note the pairs: Prepare reply and Send reply, Prepare write to SOR and Write to SOR. In each pair the first stops for a person and the second does not. Choosing between them is how you set autonomy rule by rule rather than globally.
Sender type is an authorization boundary, not a label. Get it wrong and the agent either ignores real vendor mail or answers someone it should not.
Full path
Table 4. Arrival to task
# |
Step |
Configured by |
|---|---|---|
1 |
The message is fetched from the connected mailbox. |
The mailbox connection. |
2 |
The sender is classified as External, Internal, System, or Unknown. |
Contact Management. |
3 |
The message is classified into an email category. |
Email Categories. |
4 |
Rules matching the sender and category are evaluated. |
Processing Rules. |
5 |
The matched actions run. |
The actions on each rule. |
6 |
Anything the agent may not finish alone becomes a task. |
The autonomy level and task settings. |
Diagnose by the stage that stopped
When a message stalls, find the step it stopped at, then read across for the likely cause and where to fix it.
Table 5. Where it stopped, and what to change
Stopped at |
Most likely cause |
Where to fix it |
|---|---|---|
Step 2 |
The sender is not in contacts, or the domain is not listed as internal. |
Contact Management |
Step 3 |
No category describes the message. |
Email Categories |
Step 4 |
No rule addresses that sender-and-category pair. |
Processing Rules |
Step 5 |
The action is beyond the current autonomy level. |
The autonomy level |
Step 6 |
Nothing. The task is the intended output of this step. |
Nothing |
A message that produces nothing usually failed at step 2 or 3. Check classification before rewriting rules. A correct rule cannot fire on a message that was never categorized.