Approvals on the phone – how to shorten the decision cycle in the organisation

A traditional approval process today looks like this: an email lands with a link to a separate system, the approver logs in, clicks through screens, makes the decision, returns to their work. Each such approval takes 5–10 minutes, even though the 'thinking' takes a few seconds. The rest is jumping between tools.

The practical change introduced by modern solutions inside Microsoft 365: the approval arrives directly inside the tool the employee already lives in – Microsoft Teams. They see a small, readable decision view: what it is, who is asking, key data, any warnings (e.g. invoice 30% above the supplier's average). Below: two, sometimes three buttons – approve, reject, return with comment. The decision takes 10–30 seconds.

The business consequence is real. For an employee handling 50 approvals per month that is 4–8 hours of reclaimed time. For an organisation with 100 such people – 400–800 hours per month freed from administration. But the more important effect is qualitative: decisions are made faster, documents do not wait for weeks, business cycles shorten. We discuss the wider context in our article on approval bottlenecks.

The second change is even more important: the same thing works equally well on a phone and on a computer. A manager in transit, a salesperson in a meeting, a board member on a train – they can all decide instantly, without waiting to be back at the desk.

From the approver's perspective a good approval has three zones. The first, in 2 seconds, tells them: what is it and from whom. An invoice from supplier ABC. A leave request from Mr Smith. A contract with customer XYZ. Without this information the decision has to wait.

The second zone, in 5 seconds, shows the context needed to decide. For an invoice: net/VAT/gross, category, whether it matches the order, anything unusual (e.g. 30% higher than this supplier's average). For a contract: counterparty, value, duration, clauses that deviate from the company standard. 5–8 key facts, not 30 fields lifted from a source system.

The third zone is the action itself. Three buttons at most – approve, reject, return with comment. Each with a clear label and clear consequence. No 'cancel', no 'save', no 'go next' – approval is a one-way decision, not a form. If the approver needs more context, they click 'show full document' – but in 90% of cases they do not need to.

Practical observation: organisations that overload the approval with 30 fields and 10 buttons get low adoption. Decisions slip back to email threads because every in-system approval feels heavy. Good design is minimalist – only what is genuinely needed to decide.

From our experience three simple patterns cover the vast majority of approval processes in mid-sized and large organisations. Worth understanding, because the choice of pattern decides how quickly and predictably the process runs.

Pattern one: sequential approval. Direct manager first, then finance director, then – if the amount exceeds a threshold – the board. The classic model, great for spend and contracts. Requires a simple escalation rule if someone does not respond in X working days – otherwise it becomes the same bottleneck as before, in a new tool.

Pattern two: parallel approval. Several people receive the case at the same time; one approval is enough. Works where speed matters and several people have equivalent authority (e.g. approving an urgent IT access, approving a refund to a customer). Dramatically shortens the decision cycle.

Pattern three: majority approval. The decision requires the consent of the majority – e.g. 3 of 5 board members, 2 of 3 regional directors. Used for strategic decisions and requests that should not depend on one person. Built-in voting eliminates the need for separate decision meetings for routine cases.

All three patterns are natively supported by modern process-automation tooling. Choosing a pattern is an organisational decision – not a technical one.

In mature organisations 40–60% of approvals today happen on a phone. This is not a luxury – it is how senior management actually works, between meetings, on the road, in transit. Without a working mobile experience the process stops on the manager's calendar.

Three rules decide whether mobile approvals are used. First: readability on a small screen. The decision takes seconds only if you can see everything without scrolling. That requires deliberately limiting the number of fields (4–5 instead of 8) and buttons large enough to hit with a finger on the first try.

Second: notifications that actually carry information. A message that says 'Notification from the system' gets ignored. A message that says 'Invoice ABC – 12,500 EUR – approval needed within 24h' gets clicked. Notifications must be self-contained, so the recipient knows whether to open it now or in an hour.

Third: no separate app to install. Approvals live in the tool senior management already uses every day (Microsoft Teams). Every additional 'install the app, log in, configure notifications' step is a barrier that lowers adoption.

Microsoft provides the Adaptive Cards Designer – an online tool with preview across channels (Teams Desktop, Teams Mobile, Outlook). Building an adaptive card is configuring JSON schema, basic templating, sample values. The Designer also exports JSON for use in Power Automate.

The second tool is templates. Microsoft and the community publish templates for typical scenarios: invoice approval, contract review, HR request, project approval, generic information card. These templates are starting points but require adaptation to specific organisational metadata.

The third tools are SDKs – .NET, JavaScript, Python, Java – allowing adaptive cards to be built programmatically. Used in more advanced scenarios (e.g. dynamic LLM content), where card content is generated at workflow execution.

The fourth dimension is A/B testing. The best organisations test different adaptive card versions on small groups before full rollout – measuring cycle time, completion rate, escalation rate. Data-driven optimisation, not intuition.

Adaptive Cards combined with Microsoft Copilot and AI extraction give the most modern approval workflow stack. Pattern one: AI-generated summary. The workflow extracts fields from the document (IDP, Copilot), Copilot generates a 2–3 sentence summary ('Invoice from supplier X for amount Y, marketing category, matches PO 12345, one anomaly: 30% above 12-month average'). That summary lands in the adaptive card.

Pattern two: anomaly flagging. AI compares the document to a historical profile and flags deviations – an unusual supplier, an out-of-range amount, a clause deviating from the template. Anomalies appear in the adaptive card as colour-coded tags, reducing the risk of 'rubber-stamp approvals'.

Pattern three: contextual Q&A. The adaptive card includes a button 'Ask AI about this document', which opens a mini-chat in Teams (via Bot Framework or Copilot Studio). The approver can ask a contextual question ('show deviating clauses', 'compare with the last contract') without leaving the flow.

Pattern four: suggested decision. AI suggests a decision with reasoning ('Recommended approve – document aligned with policy, no anomalies'). This does not replace the human decision but speeds it up for typical cases. It requires AI governance – not every scenario is appropriate for AI suggestions.

The first mistake is trying to turn the card into a full portal. 30 fields, 10 buttons, edit-anywhere. The approver gets lost in the screen and stalls the decision. A card is a micro-UI for a decision, not an application.

The second mistake is no mobile testing. The card looks fine in Adaptive Cards Designer and in Teams Desktop, but in Teams Mobile fields are truncated, layouts misalign, action buttons are hard to hit. Every card must be tested in Teams Mobile before rollout.

The third mistake is inadequate notifications. A mobile push with the title 'Power Automate notification' instead of 'Invoice ABC – 12,500 EUR – approval needed'. The approver ignores notifications, the case waits for weeks.

The fourth mistake is missing audit trail. The workflow logs the action but does not validate identity – approval may be attributed to a bot or a service account. Adaptive Cards with Bot Framework must use Entra ID auth.

The fifth mistake is unclear language in the card. Technical jargon, unexplained acronyms, identifiers without context. An Adaptive Card is for business, not developers.

Do Adaptive Cards work only in Teams? No. They render in Teams, Outlook, Windows Notifications, Power BI, Webex (via integration) and custom apps through Bot Framework. Teams is the most common channel for approvals.

Do I need Power Automate to use Adaptive Cards? Not mandatory, but it is the most common stack. Alternatives: Bot Framework + Azure Bot Service, custom code with SDKs, integration via Microsoft Graph API.

What is the mobile approval adoption rate? In mature workflows 40–60% of approvals come from Teams Mobile. The growth is gradual – the first weeks 10–20%, after 6 months 40–60%, then stable. Good push notifications are critical.

Can I use Adaptive Cards for a CAPA workflow with FDA 21 CFR Part 11? Yes, but it requires e-signature compliance (MFA, non-repudiation) and audit trail – we cover this in our CAPA medtech workflow article.

Which Adaptive Cards version to pick? Currently 1.5+ for Teams, 1.4+ for Outlook (feature differences). Microsoft publishes a compatibility matrix – check before the project.

Can adaptive cards be edited after they are sent? Yes – the workflow can update the card content (via the 'Update card' action). Pattern: after approval the card shows 'Approved by X at Y', so the approver cannot undo it.

Can I use HTML/CSS in Adaptive Cards? No. The format uses JSON schema with predefined elements (TextBlock, Image, ColumnSet, ActionSet etc.). No custom HTML is a limitation but yields cross-platform consistency.

Adaptive Cards in Microsoft Teams are today the standard of modern workflow approvals in the Microsoft ecosystem. They combine brevity, context, one-click decisions and full audit trail in the same tool employees use every day. Mobile-first design enables 40–60% of approvals on mobile, which fundamentally changes the economics of decisions.

The key is disciplined design: 5–8 body fields, max 3 actions, mobile-first layout, good notifications, AI integration for summaries and anomaly flagging. Without this discipline the adaptive card becomes a portal glued onto Teams – losing most of its advantages.

The most sensible first step is to pick one workflow (e.g. invoice approval with IDP) and design the first adaptive card. After a 4–6 week pilot, the organisation has a pattern, governance and templates for the next workflows. At AlgorComp we support adaptive card design as part of implementation and growth for workflow automation.