Google Sheets
An agent can write a row into a spreadsheet when a conversation ends, and read from one while a conversation is still going. A lead, an order, a callback request on one side; an order status the caller is asking about on the other.
Connect
Go to Settings - Integrations, choose Google Sheets, name the connection and press Connect. You approve access on Google's own screen and land back here.
Unlike the other integrations, this one asks you nothing before you connect. It cannot: choosing a spreadsheet needs the access Google is about to grant. So the connection arrives unfinished and the card asks you to Choose a spreadsheet.
There are two ways, and you can use either:
Let Glytos create one. A new spreadsheet appears in your own Google Drive, yours to rename, move, share or delete. Nothing else is needed.
Pick one you already have. Google's own file picker opens and you choose the file. This is the right answer when the sheet is already part of how you work.
Glytos is given the single spreadsheet you created or picked, and nothing else in your Drive. That is not a promise about our behaviour, it is the only access Google issued us. A spreadsheet you did not hand over cannot be opened by Glytos however widely it is shared, which is why pasting a link does not work.
Put your headings in the first row
The first row of the sheet is its column headings, and everything else follows from it:
| Name | Phone | Order number | Status |
|---|
The agent fills those columns by name, so you can reorder them, insert one in the middle, or rename the sheet, and the rows already written stay where they belong. A sheet with no headings is refused rather than guessed at, because writing in whatever order the model happened to use would look fine until somebody read it.
The actions
Under Tools, create a tool of kind Integration, pick the connection and choose an action:
| Action | What it does |
|---|---|
append_row | Add a row. The agent supplies a value per column heading; anything it leaves out is an empty cell |
find_row | Find one row by the value in a column, for example an order number the caller reads out |
read_rows | Read the most recent rows, for a question about the sheet as a whole |
append_row is the one that can also run as an
automation, which is how "when a call ends,
log it" works without the agent having to remember. The two read actions cannot:
a lookup on a schedule reads a row and tells nobody.
A prompt that works
When the caller gives you an order number, call find_row with column "Order
number" and the number they said. Read back the status. If there is no match,
say so and offer to take a message.
Before the call ends, call append_row with the caller's name, their phone
number and what they wanted.find_row matches ignoring case and spacing, so a caller saying "ab one two
three four" and a sheet holding AB-1234 are the same order.
Limits and behaviour
- No match is a normal answer, not an error. The agent should say there is no such order rather than apologise for a fault.
- A column the agent invents is reported back to it rather than silently dropped, so a wrong heading shows up in the call's own log.
- Reads are bounded. A lookup table an agent consults mid-call is small by nature, and a caller is waiting; a sheet with tens of thousands of rows wants a database, and an HTTP tool pointed at it is the better answer.
- Rows are written as if you had typed them, so a date lands as a date and a number as a number.