Use Cases

“We have the CRM applets — what does using them actually look like, and where does the work go once it leaves them?” Each shape below answers that for one real job: who does it, what BigLedger does behind the screen, what it leaves to a person, and how that person knows it went right. After the shapes come what they share: where their numbers come from, what goes wrong, what none of them will do for you, and a monthly check.

The running example is GadgetSphere Sdn Bhd — the retail company GS with 22 consumer-electronics branches, the online company GSO and the distribution company GSD. The thread through every shape is the same: nothing in Digital CRM posts to the ledger or moves stock. Each shape ends at the point where the work is handed to a module that does.

1. A WhatsApp enquiry that ends in a sale

A customer messages the number published for branch GS-KV-03: “Do you have the 14-inch ultraportable in grey, and can you deliver?” The message lands in the Unified Contact Center as a conversation on the WhatsApp endpoint of the Klang Valley virtual contact.

How the message becomes somebody’s task

What happens next depends on one setting the inbox does not show: whether that endpoint has a bot linked.

• With a bot linked, the bot answers first, and a task exists only once its flow reaches the hand-over element — which must carry a skill, or no task is created at all. The task then waits for the skill-based routing engine, which runs every fifteen minutes. A rule linked to the task’s queue — for the branch, ASSIGN_TO_AVAILABLE_TEAM_AGENT_WITH_LEAST_TASKS against the KV-03 team — picks the agent. If no rule matches, or no KV-03 agent is available, the rule set’s default rule runs instead; with no default rule configured, the task goes to any agent with the fewest tasks.
• With no bot, the first message of the new session creates the task at once, and a different rule set routes it in the same moment: TASK_TEAM_ASSIGNMENT_AUTOMATION_RULE_SET. That rule set is not created for you. Until somebody builds it, the task waits at CREATED for a person to pick it up.

Either way the agent who gets it sees it in My Tasks. The full build of either path is in Contact-centre automation.

From a phone number to a customer you know

The sender arrives as a new contact — a phone number and nothing else — so the side-panels are empty. The agent uses Contact Merging to link the number to the customer’s existing record; from then on the panels show that customer’s transaction history and e-invoices. Merging is always a person’s decision: nothing links two identities on its own.

If the customer is new, the agent creates them in Customer Maintenance first, and this is where a chat goes wrong most quietly. A customer record exists from the moment the agent presses New, as a TEMP row with no code, and the form promotes it only once it has a name, a currency and an AR/AP type. An agent who stops at the name — because the customer has just sent the next message — leaves an unfinished row behind. And a customer finished without the AR/AP type that a sale needs is a problem two modules away: the debtor reports leave out a customer with no AR type, and an invoice raised to one posts no journal.

Where the sale leaves the contact centre

From the Product panel the agent shares the item; from the Shopping cart panel they open a cart for the customer, who pays on the link. From that moment the sale belongs to the Shopping Cart: the document, the stock effect and the posting are all in E-Commerce. If the customer asks for an e-invoice, the E-Invoice panel requests one, and MyInvois Admin owns it from there.

Then the agent completes the task. Nothing else will: tasks are not closed by expiry. There is no ticket SLA clock, no satisfaction survey and no sentiment score; the Task and Agent reports show durations and counts.

Whose job, and how they know. The agent answers, merges and completes. The contact-centre supervisor owns two things the product leaves open. At the end of each shift they read the task listing for anything still open and close or reassign it, because an open task is never closed for them. Once a month they run a Monthly QA round, which draws a random sample of each agent’s completed tasks for a reviewer to read. A task nobody completed is never in the sample — so an agent who leaves work open is also an agent whose work is never reviewed. The supervisor knows the desk is healthy when yesterday’s tasks are all COMPLETED or CANCELLED and every agent has lines in this month’s round.

2. A corporate lead for GadgetSphere Distribution

A school’s procurement office e-mails GSD asking for 40 tablets and a charging trolley.

1. A sales executive records a lead in Sales Force Automation: title 40 tablets + trolley, the organisation (the school — created from the lead form’s Select Organization picker if it is new), the procurement officer’s name, phone and e-mail, and then the B2B project first, because the source, stage, type and rating drop-downs are all filtered by it. The probability is not typed: it arrives with the rating.
2. As the conversation progresses the executive moves the stage along the list GSD defined, and when the school is serious uses the lead’s Lead-To-Deal tab. That builds a deal from the lead in the browser and posts it; the deal then carries activities, comments, a work log and line items. Nothing marks the lead as converted, so pressing the button twice makes two deals.
3. When the school wants a price, the executive raises a Sales Quotation (Internal) in Sales against a customer record they create first in Customer Maintenance. The lead does not become the quotation, the order or the customer; each is keyed again.
4. The order, delivery and invoice follow the Sales chain. Credit terms for the school are on its customer record in Core, not on the lead.

Plan as the first user. Across the companies on BigLedger the lead and deal registers are, at the time of writing, unused. That is not a reason to avoid them, but it is a reason to rehearse the whole path — project lists, a lead, Lead-To-Deal, the quotation — on one test school before the sales team depends on it.

Whose job, and how they know. The sales manager decides the convention the product does not enforce: which stage means “converted”, and that the executive moves the lead to it in the same minute they press Lead-To-Deal. The executive re-keys the school into Customer Maintenance and the quotation — there is no hand-off to rely on. The manager knows the register is honest when every lead at the converted stage has exactly one deal. The deal is how they tell: the conversion appends this was converted from lead guid and the lead’s key to every deal’s description.

3. A branch-manager event and what it cost

Retail operations runs a one-day product-launch briefing for the 22 branch managers.

1. In the Event Management Applet, the operations coordinator has a calendar Retail Ops whose members are the operations team and the 22 branch managers — participants are picked from a calendar’s members, so the managers are added there first. They create the event — company GadgetSphere Sdn Bhd, start date, themselves as PIC — add the 22 managers as participants and attach the agenda PDF.
2. Nobody is notified. The applet sends no e-mail, SMS or push when an event is created or changed; the coordinator announces it out of band.
3. Managers from Penang, Johor Bahru, Kota Kinabalu and Kuching claim their travel through the Claim applet, and each claim line is tagged with the event on the claims side.
4. Two weeks later the finance lead opens the event’s Expenses tab and the Event Expense Report: the tagged claim lines by claimant and expense item, and the totals. The lines include claims still pending approval, pending document review or on hold as well as approved ones, so the event’s cost is the approved figure, and it is only final once every claim on the list has been decided. There is no budget on the event to compare it with; the comparison is a spreadsheet.

Two things to know before relying on step 4. The Expenses screens are claim reports: they open for someone holding claim-report permission, whatever their calendar permissions. And no company on BigLedger has yet tagged a claim line with an event, so the first time you do it, check the report against the claims by hand.

What does not happen: no registration page, no ticketing, no QR check-in, no survey. Attendance is the participant list.

Whose job, and how they know. The coordinator announces the event and keeps the participant list true. Each claimant tags the event on their claim line — if they forget, the cost goes missing from the event and nobody is told. The finance lead quotes the event’s cost only when every line on the Expenses tab is approved or rejected, and knows the figure is complete when the number of claimants on the tab matches the managers who travelled.

4. An overdue account — where credit control actually is

GSD’s receivables show a corporate customer 75 days past a 30-day term. Nothing in Digital CRM knows. Credit control lives in Core and Financial Accounting. The shape is here because the customer may well message the contact centre before anyone in finance calls them.

Which ageing figure you are looking at

The Debtor Report has two kinds of ageing, and they answer different questions. The Aging Report and Outstanding Document Report are worked out when you open them, from each invoice’s balance as it stands now — use them for the call list. The historical reports read a monthly copy: a job early on the 1st, where its clock is installed and active, copies every open balance and labels it as at the last day of the previous month. If that job runs late, the copy carries that day’s balances under last month-end’s date, and the monthly job does not go back and correct it. Quote the historical figure for “what was owed at month-end”; quote the live one for “what is owed now”. The Statement of Account applet sends the statement.

What stops the next order

ENTITY_BLACKLIST_CUSTOMER_PROCESSOR (Blacklist Overdue Customer in the Scheduler applet’s processor picker), when it runs, first clears every BLACKLISTED status in the tenant and then re-applies them from outstanding-versus-limit and age-versus-terms. This customer is caught by the age test only if the 30-day term is set as a company-level credit term for GSD; a term held only as the customer’s default is never consulted. When it is caught, it is the Credit Limit Status on Customer Maintenance that becomes BLACKLISTED, not the term status, so the refusal at FINAL — on a cash bill, sales invoice, sales order or outbound delivery order — speaks of the credit limit even though the balance may be well inside it. The sweep is not scheduled by default, so check the Scheduler for an active entry before relying on it.

Once the account is settled, the status comes off at the next sweep, which clears every BLACKLISTED value before it re-tests, or by hand. The same clearing step also removes any stop somebody set by hand for another reason, so a hand-set block lasts only until the next run.

What the contact centre knows about it

Nothing. The contact centre’s panels do not show credit status, and the lead register does not read it. If the customer messages the contact centre, the agent sees a merged contact with a transaction history and must look the credit status up in Customer Maintenance before promising anything on terms.

Whose job, and how they know. The credit controller builds the week’s list from the live ageing, decides who goes on stop, and keeps their own list of every stop with its date and reason — because a sweep run will wipe the hand-set ones. The contact-centre supervisor tells agents which customers must not be offered terms; the product will not tell them. The controller knows the stops held when, the day after any sweep, every customer on their list still reads BLACKLISTED. The step-by-step version is Stopping a customer and Chasing overdue accounts.

5. If you are an audit or tax practice

The Engagement Applet is for you, not for a retailer. GadgetSphere’s auditor loads one engagement per group company — customer entity GadgetSphere Sdn Bhd, billing branch the practice’s KL office, engagement roles for the partner, manager and senior, one fiscal-year-end record per year with its own team — through the ETL endpoints, and maintains roles and year ends on screen. The documents the practice raises against the engagement appear on its Gen Doc tab; the claims its staff book while on the engagement are the Claims module’s.

Whose job, and how they know. The practice’s administrator loads the client files and opens each one on screen once: its running number is given at that first edit, and the first edit is also when a company, branch or entity the load named that does not exist is caught. They know the load is complete when every engagement on the listing carries a number.

What these shapes have in common

• What must exist first. The customer record, with its AR/AP type — every shape that ends in a sale or a stop reads it. For the contact centre, a project, a virtual contact with one endpoint per channel, and agents; for leads, a project with its own sources, stages, types and ratings; for events, calendar members before participants. The full list is in Configuration.
• What becomes possible. A merged contact is what lets an agent see the customer’s history, open a cart and request an e-invoice. A deal carries the activity a lead does not. A tagged claim line is the only way an event acquires a cost.
• The sibling to choose between. A lead or a Sales Inquiry: the lead gives you a stage list to manage a pipeline by; the inquiry is a Sales document a quotation can follow from. Contact Merging or a customer merge: the first joins a chat identity to a record you have, the second fixes two records for one person (Duplicate customers).
• What breaks elsewhere when one is wrong. A customer created mid-chat with no AR/AP type is left out of the debtor reports and posts no journal when it is invoiced. A forgotten event tag leaves the claim in the claims module and the event’s cost short. A sweep run without warning lifts every hand-set stop at once.
• What it pairs with in practice. The contact centre leans on Customer Maintenance for every merge and on the Shopping Cart for every sale; the event calendar leans on the Claim applet for every ringgit it reports; the credit stop leans on the Scheduler, or on a person.

Where the numbers in these shapes come from

When one of these shapes goes wrong

Shapes this module does not support

Each one is a job a person still does. After each, who does it.

• A drip sequence that e-mails the WhatsApp customer seven days after purchase — not from these applets. The contact centre’s Broadcast sends one message to one audience, once. Scheduled and recurring campaigns against an uploaded contact segment are a different applet, Digital Marketing, which this wiki does not document — see what the module has no engine for. Until then, the marketing lead decides the follow-up and sends it as a Broadcast on the day.
• A churn alert on a VIP customer — no model computes one. The account manager reads the customer’s transaction history at a fixed interval and notices the gap themselves.
• A lead that auto-creates a quotation, order, customer or deal — the registers are separate. The one automatic step in the module is the older sales-force build’s CSV import, which can raise a contact-centre outbound task per imported lead. The sales executive re-keys each step, and the manager’s converted-stage check (shape 2) is what proves nothing was skipped.
• An event that takes registrations or payments — see shape 3. The coordinator collects replies outside BigLedger and keeps the participant list in step with them.
• A response-time target or a satisfaction score — the reports count; they do not judge. The supervisor reads the Monthly QA sample and decides what good looks like.

How you know a month went right

About fifteen minutes on the last working day.

1. No task is left open (shape 1). Run the Task Report for the month and read its Task Status column. You are done when every task older than a day is COMPLETED or CANCELLED, or has a reason.
2. Every agent was reviewed (shape 1). This month’s Monthly QA round has lines for every agent. You are done when each line’s questions are answered.
3. Leads and deals agree (shape 2). Every lead at your converted stage has exactly one deal whose description says it was converted from that lead. You are done when there are no duplicates and no orphans.
4. Event costs are final (shape 3). Every claim line on last month’s events is approved or rejected. You are done when nothing on the Expenses tab is pending or on hold.
5. The stops survived (shape 4). Open each customer on the credit controller’s stop list in Customer Maintenance. You are done when every one still reads BLACKLISTED. If the sweep is scheduled, check its effect — the customers it should have stopped — not its Last Run Date, which records that the clock fired, not that the job worked (Scheduler).

Where to go next