Every process in the catalog has the same cut as the entry offer: one result, up to three source systems, one approval step at the point where the decision is made today. You see what goes in, what comes out, and who approves.
These processes start the conversation; they are not finished packages. Scope, access, and acceptance criteria are defined for your environment; the fixed price is set after step 1 of the approach.
Filter by area and read each process from what happens by hand today to what is on the table at the end. The approval step and the fixed rule are listed with every process, before anything leaves the company or a system is changed.
Service
Pre-sorting incoming requests
What goes in
Everything that lands in the shared mailbox: enquiries, complaints, and questions about orders. Today somebody reads every message, assigns it, and answers it by hand.
What comes out
Every message is matched to a topic, a customer, and a responsible person, with an urgency and a draft reply that refers to the known case.
Typical source systems
Outlook (Microsoft 365)
CRM
Ticket system
What gets prepared
Identify the topic, the customer, and the urgency from the message and its attachments.
Match the message to the existing case in the ticket system or open a new one.
Prepare a draft reply that refers to the order, the customer history, and the responsible person.
Who approves
Approved by a person Nothing is sent before the responsible person has read and approved the draft.
Fixed rule Messages without a recognisable topic are not assigned; they are presented to the responsible person as exceptions.
What is on the table at the end
Assigned case in the ticket system with customer, topic, and urgency
Draft reply in the mailbox, submitted for approval
For your environmentThe source systems named are typical for this kind of task. Which of them are connected in your case, with which interfaces, permissions, and rules, is defined in step 1.
Sales
Preparing a quote
What goes in
An enquiry with an opportunity recorded in the CRM. Prices, terms, and availability sit in the ERP; the quote template lives in SharePoint. Today somebody pulls it all together by hand.
What comes out
A complete draft quote in your template: line items, prices, delivery time, and terms taken from the systems, every figure with its source, deviations from the price list flagged.
Typical source systems
CRM
ERP (e.g. SAP)
SharePoint (Microsoft 365)
What gets prepared
Take the enquiry, the contact, and the requested items from the opportunity.
Look up prices, discount tiers, stock, and delivery times per line item in the ERP.
Fill the template and flag deviations from the price list and standard terms.
Who approves
Approved by a person The quote only goes out once the person accountable for it has approved prices and terms.
Fixed rule Discounts above the agreed limit are not entered; they are handed to approval as an open item.
What is on the table at the end
Draft quote in your template, every figure with its source
Opportunity in the CRM with quote status and open items
For your environmentThe source systems named are typical for this kind of task. Which of them are connected in your case, with which interfaces, permissions, and rules, is defined in step 1.
Finance
Checking an incoming invoice
What goes in
A supplier invoice arriving by email. The purchase order and goods receipt sit in the ERP; the books are kept in DATEV. Today somebody compares items, quantities, and prices by hand.
What comes out
A checked invoice linked to its purchase order: items, quantities, and prices reconciled, deviations and missing mandatory details named, account assignment proposed.
Typical source systems
Outlook (Microsoft 365)
ERP (e.g. SAP)
DATEV
What gets prepared
Capture invoice data and mandatory details from the document.
Reconcile items, quantities, and prices against the purchase order and goods receipt in the ERP.
Prepare the account assignment proposal and the deviation list for approval.
Who approves
Approved by a person Nothing is posted or paid until the person accountable for the invoice has approved the deviations and the account assignment.
Fixed rule Invoices without a purchase order reference or with a price deviation beyond the agreed tolerance are not pre-assigned; they are presented as exceptions.
What is on the table at the end
Checked invoice with purchase order reference, deviation list, and account assignment proposal
Document prepared for posting in DATEV
For your environmentThe source systems named are typical for this kind of task. Which of them are connected in your case, with which interfaces, permissions, and rules, is defined in step 1.
Sales
Assembling documents
What goes in
Recurring documents for customers or tenders: proof of service, project report, company profile. The template and the versions last sent sit in SharePoint, order data in the ERP, key figures in DATEV. Today it is copied and looked up by hand.
What comes out
A draft in your template in which every statement points back to its source. Anything that departs from the template or the last version is flagged; anything missing is named as an open item.
Typical source systems
SharePoint (Microsoft 365)
ERP
DATEV
What gets prepared
Load the template and the version last sent; identify mandatory sections and placeholders.
Insert order data, master data, and key figures from the ERP and DATEV, each with its source.
Flag deviations from the previous version and list open items.
Who approves
Approved by a person Signed off by the person who puts their name to it, not by the system.
Fixed rule Statements without a source in one of the systems are not filled in; they are left as open items.
What is on the table at the end
Draft in your template with a source reference per statement
List of deviations and open items for sign-off
For your environmentThe source systems named are typical for this kind of task. Which of them are connected in your case, with which interfaces, permissions, and rules, is defined in step 1.
Administration
Preparing an approval
What goes in
A receipt, a contract draft, or an application arriving by email or in SharePoint, plus the rule it is checked against: purchasing policy, approval limits, contract standards. Today somebody reads through everything and decides.
What comes out
The check points are worked through, deviations from the rule are named, and the decision sits prepared and reasoned with the person accountable for it.
Typical source systems
Outlook (Microsoft 365)
SharePoint (Microsoft 365)
ERP
What gets prepared
Capture the parties, amounts, terms, and conditions from the document.
Work through every check point of the rule and reconcile it with order and budget data from the ERP.
Prepare the decision paper with deviations, reasoning, and a recommendation.
Who approves
Approved by a person Decided by the person accountable for the approval. The process prepares; it does not decide.
Fixed rule Cases above the agreed approval limit or without a stored rule are not assessed; they are presented unassessed.
What is on the table at the end
Completed check list with a reference per check point
Reasoned decision paper for the accountable person
For your environmentThe source systems named are typical for this kind of task. Which of them are connected in your case, with which interfaces, permissions, and rules, is defined in step 1.
Administration
Reconciling master data
What goes in
Customer and supplier master data maintained separately in the CRM, the ERP, and DATEV: addresses, contacts, payment terms, tax numbers. Today a deviation is only noticed when an invoice bounces.
What comes out
A deviation list per record with the leading value, its source, and a proposed correction. Changes are made only after approval, and only in the agreed leading system.
Typical source systems
CRM
ERP
DATEV
What gets prepared
Match records by customer number, name, and tax number and compare them field by field.
For each deviation, determine the leading value and formulate a proposed correction with its source.
Compile the approved corrections for the leading system and log them.
Who approves
Approved by a person No record is changed before the person accountable for the master data has approved the correction.
Fixed rule A leading system is defined per field. Changes in the other systems are proposed, not executed.
What is on the table at the end
Deviation list per record with proposed correction and source
Log of approved corrections per system
For your environmentThe source systems named are typical for this kind of task. Which of them are connected in your case, with which interfaces, permissions, and rules, is defined in step 1.
No example currently matches this area. Choose another area or show all processes.
Before go-live
Three things are settled before a process goes live.
A process from the catalog only goes into operation once access to the source systems is in place, a person is accountable for it, and it is clear what it may and may not do.
01
Access before implementation
We check in your environment which interfaces are reachable, who owns the data, and which actions the process is allowed to perform.
02
Approval before change
Before anything leaves the company or a system is changed, the person who decides today approves. The process prepares; it does not decide.
03
Evidence per run
Which sources were used, who approved, what was left as an exception, and what the AI consumed stays visible for every run.
Your first process
Which process should run first in your company?
Bring the task, the systems involved, and the person who does it today. In the intro call we check whether it fits into one result, three sources, and one approval step.