Service orders
Internal team service orders organized on a board by stages: opened from within a chat, created manually, by the AI or by the Copilot, with an owner, deadline, priority, a timeline of comments and attachments, a chat summary written by the AI and WhatsApp notices for whoever needs to act. By type, the service order can also be created in the provider's ERP and tracked over there.
What service orders are
A service order is the record of a request that needs to leave the conversation with the customer and go through another person or department of the internet service provider (ISP): a technical visit, a network repair, an installation, an invoice adjustment, an internal check in the system. While the WhatsApp chat takes care of the conversation, the service order takes care of the work that comes after it, with its own owner, deadline and history. When the provider turns the integration on, the service order can also be created in the ERP and tracked over there (see In the provider's ERP).
The module is in the side menu, in the service section, under Service orders, with the subtitle Service orders opened from a chat or on their own, organized by stage. Every logged-in user can access the screen; what changes from person to person is what each one can edit (see Who can do what).
Main concepts
| Concept | What it is |
|---|---|
| Number | Each service order gets a sequential number in the format OS-000123, used in search, in notices and in the notes that appear in the chat. Service orders opened before the module was renamed keep their old T- number. The Copy number button in the detail view copies this code. |
| Stage | The board column the service order is in (for example Open, Under review, Resolved). Each stage has a nature that defines how the system treats it. |
| Type | The service order category (for example Technical visit, Network repair). The type brings the default team, priority and deadline. |
| Team | The department that handles the service order. Its members receive the notice of a new unassigned service order. |
| Owner | The person who has the service order. An unassigned service order is available for anyone to take over. |
| Deadline | Date and time limit for completion. The deadline runs until the service order enters a final stage. |
| Source | Where the service order came from: Support (opened from a conversation), Manual (created on the service orders screen), AI (opened by the service AI) or Copilot. |
| Linked chat | The conversation the service order was created from, when there is one. The link brings the chat history and the summary written by the AI into the service order. |
The customer never sees the service order. Comments, attachments and changes are internal to the team. When the service order is created from a chat, the chat receives only internal record lines, which do not reach the customer either.
The service orders screen
The screen is divided into three bands: the search and filter bar at the top, the summary cards right below it and, finally, the board (or the list) with the service orders.
Summary cards
The five cards show the overall situation and work as shortcuts: clicking one of them applies the corresponding filter.
| Card | What it counts | Filter applied when clicked |
|---|---|---|
| Open | Service orders in any stage that is not final. | All |
| With me | Open service orders where you are the owner. | Mine |
| Unassigned | Open service orders that do not have an owner yet. | Unassigned |
| Overdue | Open service orders with a past-due deadline. | Overdue |
| Resolved today | Service orders that entered a stage of resolved nature today. | Done |
Status tabs
Right next to the search are the tabs that define which service orders appear. The numbers next to each tab follow the summary cards.
| Tab | What it shows |
|---|---|
| All | All open service orders, plus the recently completed ones (by default, those with activity in the last 7 days). This way the final columns of the board do not pile up old service orders. |
| Mine | Open service orders where you are the owner. |
| My team | Open service orders that are with you or that belong to any team (department) you are part of. |
| Unassigned | Open service orders without an owner, ready for someone to take over. |
| Overdue | Open service orders whose deadline has already passed. |
| Done | Service orders in final stages (resolved or canceled). When you enter this tab, the From and Until period is filled in with today's date; adjust the dates to see other days. |
Search and filters
- Search by number, title, customer or protocol: searches the service order number, title, description, customer name and phone number, address and the protocol of the linked chat. The search runs on its own as you type.
- Type, Priority and Team: lists that restrict the board to a type, a priority or a department.
- From and Until: period in which the service order was opened. In the Done tab, the period applies to the completion date. When you enter a period, the automatic window of recently completed service orders no longer applies and the chosen dates take over.
The dates that the Done tab fills in on its own are cleared when you switch tabs. If you changed the dates yourself, they remain in effect in the other tabs until you clear the fields.
Board and list
On the right side of the bar, the Board and List buttons switch the display mode. The choice is stored in the browser.
- Board: one column per active stage, in the configured order, with the name, color and service order count of each one. A column without service orders shows Nothing here.
- List: a table with number, Title, Stage, Type, Priority, Owner, Customer, Deadline and Last activity. Useful for reviewing many service orders at once.
In both modes, service orders are sorted by priority (urgent first) and, within the same priority, by the most recent activity. The board refreshes on its own every 15 seconds while the screen is visible and no window is open on top of it; the Refresh button forces the query immediately.
The service order card
Each card on the board summarizes the service order without the need to open it:
- number, priority and deadline status ({time} left, Overdue by, Done on time and similar);
- title, type and customer name or phone number;
- owner (or Unassigned), number of comments and attachments and how long ago the last activity was.
Click the card (or select it and press Enter) to open the service order detail. To open a service order directly through a link, use the address of the service orders screen with the ?ticket= parameter followed by the service order's internal code; the notices and the chat notes already lead to the right service order.
Open a service order
There are two manual ways to open a service order. The fields are the same in both; the difference is that a service order opened from a conversation is already linked to it and to the ERP customer identified in it.
From the service orders screen
- Open Service orders in the side menu.
- Click New service order, at the top of the page.
- Fill in the Title (required) and the other fields that make sense.
- Click New service order at the bottom of the window. The system confirms with the message Service order OS-000123 opened. (with the generated number).
From within a chat
- With the conversation open, click the More actions button (three dots) in the chat header.
- Choose Open a service order from this chat. The option also appears in conversations that are already closed.
- The window opens with the Linked chat card (protocol, customer name and phone number) and with Customer and Phone already filled in from the conversation.
- If the conversation has photos, documents, audio or videos, the Files from this chat block appears: click the thumbnails that should be added as service order attachments (Pick which ones should become service order attachments.). There is no need to download and upload them again.
- Complete the fields and click New service order.
When the service order is opened from a conversation, three things happen in the chat: it gets the internal line Service order OS-000123 opened from this chat: followed by the title; the conversation timeline records the event; and, with the AI configured, the system asks the AI for a summary of the chat for the service order (see AI summary of the chat).
Service order fields
| Field | What it does |
|---|---|
| Title | Short subject of the service order, up to 160 characters. Required. |
| Type | Service order category. When you change the type, the window automatically adjusts the Priority and the Team to that type's default values; you can change them afterwards. |
| Priority | Low, Normal, High or Urgent. Defines the order of the cards on the board. |
| Team | Department that handles the service order, or No team set. The team receives the new service order notice when there is no owner. |
| Owner | Who takes the service order, or Nobody. Service order managers choose any active person; other users can only choose themselves. |
| Deadline | Date and time limit. If blank, the type's default deadline applies (Empty: uses the default deadline of the chosen type.). A service order without a type gets 24 hours. |
| Customer | Customer name, when the service order is about a customer. |
| Phone | Customer's WhatsApp. This is how the service order appears in the side panel of that customer's conversations. |
| Address | Service address, useful for visits and repairs. |
| Description | What the team needs to know to resolve it: symptoms, what has already been tested, address landmark, agreed time. |
| Attachments | Files sent along with the service order. See the accepted formats in Service order detail. |
| In the ERP | Block that appears when some ERP has service orders turned on: shows the ERP customer and contract, the choice of also opening it there (according to the type's behavior) and, if there is one, the service order already open in the ERP for that customer. Details in In the provider's ERP. |
Every new service order enters the first active stage of Initial (intake) nature. If no initial stage is active, the system uses the first active stage on the board.
Good practice: write the description with the person who will do the work in mind, assuming they have not read the chat. A field technician needs the address, a landmark, the symptom and the time window agreed with the customer.
Service orders opened by the AI and by the Copilot
Service AI
The AI that answers customers can open service orders on its own. The feature is off by default and is enabled in Settings, Service tab, with the AI can open internal service orders switch: When it cannot confirm the cause of an issue, the AI files a service order for the most suitable team (or unassigned for everyone to see) and tells the customer the team will check and get back, instead of speculating about the cause.
How the AI behaves with the feature on:
- It opens a service order only when it needs an internal check that no one can resolve live in that conversation, instead of guessing the cause.
- It chooses the type by name among the active registered types; with that, the service order goes to that type's team. When in doubt, it leaves the type empty and the service order stays open for the whole team.
- It writes a title and a description with what the customer reported and what has already been checked, and tells the customer that the team will check and get back, without promising a deadline or a result.
- It opens at most one service order per chat. If the chat already has an open service order, it only informs that the team is already checking.
- The service order never replaces the chat: if the customer is in the conversation waiting for an answer the AI does not have, it transfers to an agent instead of opening a service order, and opening a service order does not close the conversation.
- If creation fails for any reason, the conversation goes to the human queue, without sending the customer the message that the service order was opened.
A service order opened by the AI shows AI in Source and System in Opened by. The conversation receives the internal record line, as with any service order opened from a chat. Opening by the AI applies only when it answers the customer; in the mode where it suggests replies to the agent, it does not open service orders. If the type the AI chose has the Always: opens in the ERP as well behavior and the customer is identified in the ERP, the service order is also created in the ERP; the AI only confirms to the customer what the ERP confirmed.
More details about the AI's behavior are in AI in customer service.
Copilot
The Copilot, the assistant that works inside the panel, also sees service orders: it lists service orders with filters, details a service order by number, opens service orders (linked to the conversation when the request comes from a chat) and comments on the timeline. Service orders opened by it show Copilot in Source. See Copilot.
Service order detail
The detail opens in a wide window, divided into two columns. The window title shows the service order number and title.
Main column
- Header: number (with Copy number), stage, type, priority and deadline status.
- Description: the service order text. Whoever can edit sees the Edit service order pencil, which opens a window to change Title, Customer, Phone, Address and Description.
- Linked chat: protocol, conversation status, customer name and phone number, with the buttons View chat (opens the Chat history, with the last 200 messages of the conversation) and Open the conversation (goes to the chat). A service order without a link shows Standalone service order, no linked chat.
- In the ERP: right below the linked chat, what the service order has in the provider's ERP: number, status, technician, schedule, last check and the buttons Check now, Open in (ERP name) and Try again. An internal-only service order shows This service order exists only here. See In the provider's ERP.
- AI summary of the chat: the briefing generated by the AI, described below.
- Timeline: everything that happened in the service order, in order, with the comment box at the end.
Anyone handling the service order can read the history of the linked chat with the View chat button, even if they are not the agent of that conversation.
Side column
- Action buttons: Take over (when you are not the owner), Resolve (for whoever can edit) and, on a completed service order, Reopen.
- Fields editable in place: Stage, Owner, Priority, Type, Team and Deadline. Each change is saved immediately, with the confirmation Service order updated., and becomes a line on the timeline.
- Customer and Address, when provided.
- Record data: Opened by, Opened on, Source, Last activity and, after completion, Resolved at.
Fields you do not have permission to change appear disabled.
Timeline
Each event shows who did it (You, the colleague's name, System or the AI) and how long ago. The recorded events are:
| Event | Example of the text displayed |
|---|---|
| Opening | opened the service order |
| Comment | commented, with the text and the attachments of the comment |
| Stage change | moved from Open to In progress, with the closing comment when there is one |
| Reopening | reopened the service order (Resolved to Open) |
| Owner | took the service order, assigned to someone or removed the owner |
| Priority, type and deadline | changed priority from Normal to High, changed type from, changed the deadline from |
| Field editing | edited followed by the changed fields (title, description, customer, phone, address, team) |
| Standalone attachment | attached a file |
| Deadline passed | Deadline passed without completion., recorded by the system |
| In the ERP | opened service order 4521 in IXC, linked to service order 4521, already open in IXC, could not open in IXC followed by the reason, in IXC: Scheduled (status, technician or schedule change) and completed in IXC, with the ERP's closing text |
Comments and attachments
- Write in the box Write an update for the team (the customer never sees it).
- To attach, use Attach file, drag files onto the area or paste an image with Ctrl+V (Paste images with Ctrl+V, drag or pick files (up to 45 MB each).). A pasted image without a name gets a name with date and time.
- Click Comment or use Ctrl+Enter.
With text, the comment is saved first and the files are attached to it. With files only, each file becomes an attachment event. The chosen files survive stage or priority changes made before commenting.
| Attachment rule | Value |
|---|---|
| Maximum size per file | 45 MB (above that: File larger than 45 MB.) |
| Accepted formats | JPEG, PNG, GIF and WebP images; PDF; text and CSV; ZIP; MP4 video; OGG, MP3 and M4A audio; Word documents and Excel spreadsheets. Other formats are refused with File type not accepted in service orders. |
| Files from the chat | Up to 30 files from the conversation can be selected when opening. The service order keeps its own copy, which remains available even if the conversation is deleted later. |
The format is checked by the file content, not by the file name extension. Images appear as thumbnails on the timeline; other files appear with their name and size and open in a new tab.
AI summary of the chat
When the service order has a linked chat and the AI is configured, the system asks the AI for a briefing of the conversation for whoever will handle the service order. While the summary is being prepared, the block shows The AI is writing the summary. It shows up here in a moment. and the window checks on its own for a few minutes until it arrives.
- The summary is requested when the service order is opened and can be generated with the conversation still in progress. Media-only messages (for example, a photo of the problem without a caption) also count as conversation content.
- When the chat is closed, the service orders of that conversation that are still open get a new summary, which covers the entire conversation.
- The Refresh button, next to the summary date, requests a new summary at any time.
- If a summary never arrived (for example, the AI was unavailable when the service order was opened), opening the service order detail requests it again, without you having to do anything.
Below the service order summary, the Chat summary (generated at closing) block may also appear, which is the summary the conversation itself receives when it is closed.
Without AI configured in the system, the service order works normally; only the summary block does not appear. See AI in customer service.
Move the service order between stages
There are three ways to change a service order's stage:
- Drag the card on the board to another column (Drag the card to another stage.). The card changes column immediately; if the server refuses the change or the network fails, it returns to the original column and a notice appears. You can only drag service orders you are allowed to edit.
- Change the Stage field in the side column of the detail.
- Use the Resolve button (goes to the first stage of resolved nature) and the Reopen button (goes to the initial stage).
From the detail, moving to a final stage opens a Move to window with the Comment (optional) field, to record what was done. The comment enters the timeline along with the change.
What the system does on each move
| Situation | Behavior |
|---|---|
| First time in a stage of In progress nature | Records the start of work on the service order. |
| Unassigned service order moved to a work stage | Whoever moved it automatically becomes the owner. Does not apply to the initial stage or to a final stage. |
| Entry into a Final: resolved stage | Saves the resolution date, closes the deadline (met or missed) and notifies whoever opened the service order. |
| Entry into a Final: cancelled stage | Closes the service order and the deadline and notifies whoever opened it. |
| Leaving a final stage for an open stage | Becomes reopened the service order on the timeline and clears the completion dates. |
| The ERP completes the service order that is also open there | The service order here goes on its own to the first stage of Final: resolved nature, with the ERP's closing text as a comment and the ERP's name as the author. See In the provider's ERP. |
When the service order has a linked chat and the conversation has not been closed yet, each move appears in the chat as an internal line, for example Service order OS-000123 moved to stage In progress by someone. This way, whoever is serving the customer knows the service order moved forward without leaving the conversation.
Owner and team
The service order can be with a person (owner), with a team (department) or with both. A service order with a team and no owner is the way to make the request available to the department: everyone in that department is notified and anyone can take it over.
Take over
The Take over button makes you the owner. Any user can take over a service order, including one that already has an owner. The timeline records took the service order and the linked chat receives Service order OS-000123 taken over by you.
Assign to another person
To choose another person in the Owner field, or to leave the service order with Nobody, you must be a service order manager or the current owner. The chosen person receives a notice on WhatsApp (see Notices and alerts).
Change the team
Changing the Team of an unassigned service order notifies the new team, as if the service order had just arrived for it.
Teams are the same departments used in customer service. Who belongs to each department is defined in the user record. See Departments and Users and profiles.
Deadlines and priority
How the deadline is set
- When opening, the deadline entered in the Deadline field prevails.
- If blank, the deadline is calculated from now with the hours in the type's Default deadline (hours).
- A type with a default deadline of zero (Zero: no automatic deadline.) creates a service order with No deadline.
- A service order without a type gets 24 hours.
- The deadline can be changed later, in the Deadline field of the detail, by whoever can edit. Changing the deadline rearms the due notice.
Deadline status
| Indicator | When it appears |
|---|---|
| {time} left (green) | Open service order, with time to spare. |
| {time} left (warning highlight) | 2 hours or less remain, or 25% or less of the total time between opening and the deadline remains. |
| Overdue by | The deadline has passed and the service order is still open. The service order counts in Overdue. |
| Done on time | The service order reached a final stage before the deadline. |
| Done past the deadline | The service order reached a final stage after the deadline. |
| No deadline | The service order has no deadline. |
Times are shown in minutes, hours (up to 48 h) or days. Hover over the indicator to see the exact date and time of the deadline.
Deadline passed
An automatic routine of the system checks deadlines continuously. When the deadline of an open service order passes, two things happen, only once per deadline: the timeline receives Deadline passed without completion. and the owner receives a notice on WhatsApp; without an owner, the notice goes to the service order's team.
Priority
The four priorities (Low, Normal, High and Urgent) sort the board and the list: urgent first. The default priority comes from the type and can be changed at any time by whoever can edit.
Service orders within the chat
The agent does not need to leave the conversation to know whether the customer has something in progress.
- Service orders block in the customer panel: in the side column of the conversation, the Service orders block lists that customer's open service orders (looked up by phone number, with and without the ninth digit), with stage, type, deadline and the latest change summarized (for example, who commented and how long ago, or the status the ERP returned). Click an item to open the detail. Without open service orders, the block shows No open service orders for this customer.
- Internal lines in the chat: opening, stage moves, owner changes, comments and what happens in the ERP appear in the linked conversation as internal lines, while the conversation is not closed. Examples: Comment by someone on service order OS-000123: followed by the beginning of the comment; OS-000123 also opened in IXC (number 4521).
- Service mode: in the dedicated service mode, the Service orders tab on the side rail brings the same board without leaving the screen.
See also Customer service and Customer panel.
Notices and alerts
WhatsApp notices
The system notifies whoever needs to act through WhatsApp. Notices are sent from the ISP's number connected to ChatISP and arrive on the user's personal WhatsApp.
| Situation | Who receives it | Text |
|---|---|---|
| New unassigned service order (or team changed on an unassigned service order) | The members of the service order's team, except whoever performed the action. A service order without a team does not generate this notice. | New service order for team (team name), number, type, title and customer, Open the panel to take it. |
| Service order assigned to someone | The new owner, if they did not assign it to themselves. | Service order assigned to you: followed by the number, type, title and customer. |
| Service order resolved or canceled | Whoever opened the service order, if they did not complete it themselves (this also applies when the completion came from the ERP). | The service order you opened is done: followed by the details and the final stage. |
| Deadline passed | The owner; without an owner, the team. | Deadline passed on service order followed by the details. |
To receive notices, the user must have WhatsApp registered and verified in their profile and the Receive WhatsApp alerts option turned on. Team notices skip whoever is on a break. See My account.
Menu counter and sound alert
The Service orders menu item shows a counter with what requires action from you: open service orders with you plus unassigned service orders of your teams (for service order managers, all unassigned ones). The counter is updated every 20 seconds. When it increases, the panel plays the Service order for you or your team alert, which each user can configure or mute in the sound preferences.
Who can do what
The service orders screen is open to all logged-in users. Each person's reach depends on the Manage service orders permission, granted in the access profile: Everyone sees the service order board. With this permission, edits any service order, assigns to other people and configures the board (stages, types, deadlines).
| Action | Without the permission | With Manage service orders |
|---|---|---|
| View the board and open the detail | Yes, all service orders | Yes |
| Open a service order | Yes, with owner Nobody or themselves | Yes, with any owner |
| Comment and attach | Yes | Yes |
| Take over | Yes | Yes |
| Edit fields, move stages, resolve and reopen | Only if they are the owner, opened the service order or the service order is unassigned | Any service order |
| Assign to another person or remove the owner | Only if they are the current owner | Any service order |
| Configure stages and types | No | Yes |
| Check now, Open in the ERP and Try again in the In the ERP block | Only on service orders they can edit | Any service order |
| Turn on service orders on the ERP card in Integrations | No | No: requires the Integrations permission |
To open a service order from a conversation, the user must be able to see that conversation. The Administrator profile has full access and counts as a service order manager. See Users and profiles.
Configure stages and types
Service order managers see the Set up button at the top of the service orders screen. It opens the window with two tabs: Board stages and Service order types. Changes take effect immediately for everyone and are recorded in the system audit log.
Board stages
Each stage becomes a board column. Click New stage or Edit on a stage row.
| Field | What it does |
|---|---|
| Name | Column title, up to 80 characters. |
| Nature | Defines how the system treats the stage: where the service order is created, when it counts as in progress and which stages close the deadline. Options below. |
| Color | Color of the column marker and of the stage badge. |
| Order | Position of the column on the board, from left to right. |
| Active | An inactive stage leaves the board and the selection lists, but still exists for the history. |
| Nature | Effect |
|---|---|
| Initial (intake) | Where new service orders are created and where Reopen leads. Moving to it does not assign an owner. |
| In progress | Work stage. The first entry marks the start of work on the service order. |
| Waiting on others | Work stage on hold (customer, supplier, another department). The deadline keeps running. |
| Final: resolved | Completes the service order, closes the deadline and counts in Resolved today. This is where Resolve leads. |
| Final: cancelled | Completes the service order and closes the deadline, without counting as resolved. |
Board safety rules:
- The board needs at least one active initial stage to receive new service orders; the system does not accept a change that leaves the board without one.
- A stage with service orders cannot be deleted (Stage has service orders and cannot be deleted. Deactivate it instead.).
Service order types
Click New type or Edit on a type row.
| Field | What it does |
|---|---|
| Name | Type name, up to 80 characters. It is also the name the AI uses to choose the type. |
| Description | Short explanation of what belongs to this type (up to 255 characters), displayed in the list of types. |
| Team | Default department. Service orders of this type go to this team, which gets the WhatsApp notice. |
| Priority | Default priority of service orders of this type. |
| Default deadline (hours) | From 0 to 8,760 hours (one year). Zero: no automatic deadline. |
| Color | Color of the type badge on the cards. |
| Order | Position in the list of types. The first active type comes selected when opening a new service order. |
| Active | An inactive type no longer appears for new service orders. |
| In the ERP | Whether a service order of this type is also created in the provider's system: Never: only here, Always: opens in the ERP as well or Ask when opening. With Always or Ask, the How it opens in (ERP name) block appears, with the fields read from the ERP itself. It only appears when some ERP has service orders turned on in Integrations. Details in In the provider's ERP. |
Deleting a type that already has service orders does not erase anything: the type just becomes inactive, and old service orders keep showing its name (Delete this type? If service orders use it, the type only becomes inactive.).
What comes preconfigured
A new installation already includes a board ready for use, which can be changed freely:
| Stages (in order) | Nature |
|---|---|
| Open | Initial (intake) |
| Under review | In progress |
| In progress | In progress |
| Waiting for customer | Waiting on others |
| Resolved | Final: resolved |
| Canceled | Final: cancelled |
| Type | What it is for | Priority | Deadline |
|---|---|---|---|
| Technical visit | The team needs to go to the customer's address. | High | 24 h |
| Network repair | Fiber break, OLT failure, splice box or concentrator failure. | Urgent | 8 h |
| Installation | Activation of a new location or change of address. | Normal | 48 h |
| Billing | Invoice adjustment, negotiation or undue charge. | Normal | 24 h |
| Other | Internal request that does not fit the other types. | Normal | 24 h |
The factory types have no team set. As long as a type has no team, its service orders are created without a team and no one receives the new service order notice on WhatsApp. All factory types come with In the ERP set to Never: only here. Set the team of each type right after creating the departments.
In the provider's ERP
The ChatISP service order can also be created in the system the provider already uses for field work (IXC, Hubsoft, SGP, Gesprov or Pipesoft), and the progress over there comes back here: status, technician, schedule and completion. The feature is optional and comes turned off: whoever turns nothing on keeps internal-only service orders, exactly as before. The decision is made per service order type, so that a technical visit goes to the ERP while a NOC analysis stays only here.
Inside the service order, what lives in the ERP appears under In the ERP, even if the ERP calls it something else over there (an occurrence in SGP, a service call with a work order in Hubsoft, a call in Gesprov and Pipesoft).
How to turn it on
- Open Integrations and find the ERP card. Turn on the Service orders in the ERP switch (When on, each service order type chooses whether it also opens here.). The card starts showing Service orders on. On Gesprov the notice Opening only: tracking stays in the ERP. also appears; on ReceitaNet the switch does not exist (This ERP has no service order integration.).
- Open Service orders, click Configure and go to the Service order types tab. The list gains the In the ERP column with each type's behavior.
- Click Edit on the type that should go to the ERP and choose under In the ERP: Always: opens in the ERP as well or Ask when opening.
- Fill in the How it opens in (ERP name) block: the system shows Reading the ERP options... and loads the subject, sector, type, reason or category straight from the ERP's own records. Pick from the lists; nothing is typed by hand. With more than one ERP turned on, there is one block per ERP.
- Save. If a required field is missing, the screen warns Fill in the required fields for (ERP) or leave this type as "Never".
The options read from the ERP are kept for one hour; the Reload options button fetches them again right away (useful after creating a new subject or sector in the ERP). If the ERP does not respond or rejects the credential, the screen shows Could not read the options from (ERP) followed by the reason, and the type can be saved as Never: only here until it is sorted out.
With the switch off in Integrations, the types tab warns Service orders in the ERP are turned off in Integrations. and every behavior is locked at Never: only here. With no ERP that has service orders registered, the notice is No ERP with service orders turned on in Integrations.
The three behaviors
| Behavior | What happens when a service order of this type is opened |
|---|---|
| Never: only here | The service order is internal only. It is the factory default for every type and the behavior as it has always been. |
| Always: opens in the ERP as well | Every service order of this type is also created in the ERP, as long as the customer is identified in the ERP. The create window shows This type always opens in (ERP) and asks for no confirmation. It applies to service orders opened by the agent, by the AI, by the Copilot and through the API. |
| Ask when opening | The create window shows the Also open in (ERP) switch, off by default. Whoever is opening decides. The AI and the Copilot do not open in the ERP with this behavior; through the API, the caller states the decision. |
The behavior applies to each ERP that is turned on. A type can go to one ERP and not to another: just fill in the mapping of the ERP you want.
The customer and the contract
The service order is only created in the ERP when ChatISP knows who the customer is over there. The link is recorded at opening:
- Service order opened from a conversation: uses the subscriber already identified in the chat (by phone number, by manual link or by the record lookup done by the AI). The In the ERP block shows the customer and, when they have more than one contract, the Contract field to choose from.
- Standalone service order: the block brings the Customer in the ERP field (Name, phone or login. Left blank, the service order stays only here.). The search looks in the ERP mirror; the Change button undoes the choice.
- Without an identified customer, the service order is created internal only and the window explains: No ERP customer identified in this chat: the service order stays only here. If the type has no mapping for the customer's ERP: This type is not mapped to (ERP): the service order stays only here.
For those with more than one ERP registered: the service order goes to the ERP where the customer was found. When each ERP serves a knowledge base, the ERP of the connection's base applies (see ERPs in Integrations).
The mapping per ERP
Each ERP asks for different information to open a service order. All of it comes from lists read from the ERP itself when the type is configured. The field names below are the ones the ERP shows, in Portuguese:
| ERP | Fields of the How it opens in (ERP) block |
|---|---|
| IXC | "Assunto" (subject) and "Setor" (sector), both required; the sector is suggested by the subject. "Prioridade" (priority: follows the service order's priority, or fixed at Baixa, Normal, Alta or Crítica), "Filial" (branch: the one of the customer's contract, or a fixed one) and "Melhor horário" (best time: Qualquer, Manhã, Tarde or Noite). |
| Hubsoft | Service call type, work order type and whether the work order is opened together with the service call (call-only types get no work order). |
| SGP | "Tipo de ocorrência" (occurrence type, required), "Gerar ordem de serviço" (generate work order, on by default), "Motivo da OS" (work order reason), "Setor" (sector), "Prioridade" (priority) and "Origem da ocorrência" (occurrence source). |
| Pipesoft | Subject (free text, the way Pipesoft works), department and priority. |
| Gesprov | "Categoria do chamado" (call category, required). |
The service order's title and description, the customer's name and phone number, the chat protocol and who opened it go into the text of the ERP's service order, so the technician over there knows where it came from.
What each ERP allows
| ERP | Opens | Tracks | Note |
|---|---|---|---|
| IXC | Yes | Yes: status, technician, schedule, closing and the service order's messages | Approved with customers in production. |
| Hubsoft | Yes | Yes: service call, work order, technician and messages | Approved with customers in production. |
| SGP | Yes | Yes: occurrence, child work orders, technician and comments | Approved with customers in production. |
| Pipesoft | Yes | Yes: call, technician, visit and messages | According to the vendor's documentation; no customer in production with the integration turned on yet. |
| Gesprov | Yes | No | Gesprov returns the call protocol but offers no lookup through the integration. The service order here shows Gesprov does not allow tracking the service order through the integration. Follow it over there. and must be completed by hand in ChatISP. |
| ReceitaNet | No | No | Opening a call only exists in ReceitaNet's paid IVR, ChatBot or CallCenter modules, with their own credential. It waits until a provider with the module asks for it. |
What to allow on the API user of each ERP
The credentials are the same ones on the ERP card in Integrations. What changes is the permission of the API user over there in the ERP:
| ERP | What the provider needs to allow |
|---|---|
| IXC | API user in the administrator group, with no sector filter and no employee filter. With a filter, IXC hides subjects, sectors or the service order itself, and reading the options fails. |
| SGP | The token must be tied to an SGP user for the work order routes (customer and invoice lookups already work with token and application only; the service order requires the user). |
| Hubsoft | Permission for the API user on the service call types and work order types chosen in the mapping. |
| Pipesoft | Call management allowed for the API user. With it denied, Pipesoft refuses the opening and the reading of the options. |
| Gesprov | Nothing beyond the current user. |
No duplicate service orders
Before opening in the ERP, ChatISP checks whether the customer (or the contract) already has an open service order there of the same type as the mapping. The create window shows Checking in (ERP)... and, if it finds one, warns There is already an open service order in (ERP), with number and date: The service order here will be linked to the existing one, without opening another. The ChatISP service order is created normally and stays tied to the existing ERP service order, with the mark Linked to a service order that was already open in the ERP. in the detail and the event linked to service order (number), already open in (ERP) on the timeline. Tracking and automatic completion work the same way.
Tracking and automatic completion
On the ERPs that track, the system checks the ERP service order on its own: every 2 minutes during the first 2 hours, every 10 minutes until a full day has passed and then every 30 minutes, until completion. The Check now button, in the In the ERP block of the detail, runs the check right away. The block shows:
- Number of the service order in the ERP (and the protocol, when the ERP works with both);
- Status in the ERP, in ChatISP's common vocabulary and, next to it, what the ERP calls it: Open, Under review, Scheduled, In progress, Waiting, Completed or No reading (the ERP returned a status ChatISP does not know);
- Technician, Scheduled for and Completed at, when the ERP provides them;
- Checked: when the last successful check was; after a failure, Last attempt with the reason.
Each change of status, technician or schedule becomes an event on the timeline (in IXC: Scheduled) and an internal line in the linked conversation, and the Service orders block of the customer panel starts showing the ERP status. When the ERP completes the service order, the ChatISP service order goes on its own to the first stage of Final: resolved nature, with the ERP's closing text as a comment and the event completed in (ERP); whoever opened it receives the completion notice as with any service order. A service order that was already in a final stage here is left untouched.
The integration sends no message to the end customer about scheduling or completion. Letting the customer know remains a decision of the agent or of the flow. The AI, in turn, only tells the customer that the service order was recorded in the provider's system once the ERP has confirmed the opening.
Open in the ERP later, and try again
A service order that was created internal only can go to the ERP at any time through the Open in (ERP) button in the In the ERP block of the detail, with the confirmation Open this service order in (ERP) as well? The button appears when the type has a mapping for the ERP and the customer is identified. When the opening failed, the block shows Could not open in (ERP) followed by the reason, the Last attempt and the Try again button; the service order keeps existing here, with the event could not open in (ERP) on the timeline. No failure disappears in silence.
Failure reasons and what to do
| Reason shown | What it means | What to do |
|---|---|---|
| ERP customer not identified | The service order has no linked ERP customer. | Link the customer in the conversation (link button in the customer panel) or open a standalone service order choosing under Customer in the ERP; then use Open in (ERP). |
| contract not provided | The ERP requires the contract and the customer has more than one. | Open the detail, choose the contract and use Try again. |
| type not mapped to this ERP | The service order type does not have the How it opens in (ERP) block filled in. | Under Configure, Service order types tab, fill in the type's mapping. |
| incomplete type mapping for this ERP | A required field is missing from the mapping (for example, the subject was deleted in the ERP). | Edit the type, use Reload options and complete the fields. |
| service orders turned off for this ERP | The switch on the ERP card is off. | Turn on Service orders in the ERP in Integrations. |
| the ERP rejected the credential or the permission | The API user cannot open or look up service orders. | Allow in the ERP what the table above asks for and test the connection on the ERP card. |
| the ERP did not respond | The ERP was down or took too long. | Wait and use Try again. Tracking checks resume on their own in 15 minutes. |
| the ERP refused to open it | The ERP answered with a rule of its own (cancelled contract, inactive subject, call limit). | Read the message that comes with the reason and fix it in the ERP. |
| unexpected response from the ERP | The ERP answered in a format ChatISP did not recognize (new version, proxy, error page). | Check the ERP address on the card and, if it persists, contact Ravi Systems support. |
| this service order is already in the ERP | Attempt to open a service order that already has a record in the ERP. | Nothing to do: use Check now. |
| no service order integration for this ERP | The customer's ERP has no service order integration (ReceitaNet). | The service order stays internal only. |
Common cases
Customer without internet who needs a visit
- In the chat, after the diagnosis, use More actions and Open a service order from this chat.
- Choose the Technical visit type (the field team comes with it, if configured), enter the Address and describe the symptom and the agreed time window.
- In Files from this chat, select the photos of the equipment the customer sent.
- The field team receives the notice, a technician takes over, moves it to In progress and, when finished, uses Resolve with a comment about what was done. Whoever opened it is notified of the completion and the customer's chat records each step.
The service order does not appear on the board
- Check the active tab: Mine, My team and Unassigned show only open service orders.
- A service order completed more than 7 days ago does not appear in All; use the Done tab with the right period.
- Check that no Type, Priority, Team or period filter was left applied.
- The service order's stage may have been deactivated; activate it again in Set up.
I cannot drag the card
Only service orders you can edit are draggable. Without the Manage service orders permission, take over the service order before moving it, or ask the owner.
The team did not receive the notice
- The service order type must have a team, and the service order must be unassigned.
- Each member needs a verified WhatsApp and Receive WhatsApp alerts turned on; whoever is on a break does not receive team notices.
- The system must have a WhatsApp number connected to send notices.
I opened the service order and it did not show up in the ERP
- Open the detail and look at the In the ERP block. This service order exists only here. means the opening in the ERP was never even attempted: the type is set to Never: only here, the Also open in (ERP) switch was left off or there was no identified ERP customer. Use Open in (ERP) to send it now.
- If the block shows Could not open in (ERP), read the reason in the Failure reasons table, fix it and use Try again.
- Check in Integrations that the ERP card shows Service orders on.
The service order showed up linked to an old ERP service order
That is the no-duplicates rule: the customer already had an open service order of the same type in the ERP, and the one here was tied to it (Linked to a service order that was already open in the ERP.). If the old one is about another matter, complete or cancel the old one in the ERP and open the new one here again; or adjust the type's mapping to a different subject or type in the ERP, because the check compares exactly the configured subject or type.
The service order in Gesprov does not update
That is expected. Gesprov accepts the call opening and returns the protocol, but offers no lookup through the integration; that is why the block shows Gesprov does not allow tracking the service order through the integration. Follow it over there. and there is no Check now. When the team completes the call in Gesprov, complete the service order here with Resolve.